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Module -I 
INTRODUCTION: 
Software Engineering is a framework for building software and is an engineering approach to 
software development. Software programs can be developed without S/E principles and 
methodologies, but they are indispensable if we want to achieve good quality software in a 
cost-effective manner. 
Engineering is the branch of science and technology concerned with the design, building, and 
use of engines, machines, and structures. It is the application of science, tools and methods to 
find cost effective solutions to simple and complex problems. 


SOFTWARE ENGINEERING is defined as a systematic, disciplined, and quantifiable approach for 
the development, operation and maintenance of software. 


The Evolving role of software: 


The dual role of Software is as follows: 

1. AProduct- Information transformer producing, managing, and displaying information. 

2. A Vehicle for delivering a product- Control of computer (operating system), the 
communication ofinformation(networks) and the creation of other programs. 


Software: 
Software is Instructions + Data Structures + Documents 
e instructions (computer programs) that when executed provide desired function and 
performance, 
e data structures that enable the programs to adequately manipulate information, and 
e documents that describe the operation and use of the programs. 
Characteristics of software 
e Software is developed or engineered, but it is not manufactured in the classical sense. 


e Software does not wear out, but it deteriorates due to change. 
The figure of failure curve is also called as 
bathtub curve indicates that hardware 


exhibits relatively high failure rates early in 
FIGURE 1.1 its life; defects are corrected and the failures 
eae Se rate drops to a steady state for some period 
FOLUTS CUTIVE +œ s X r : 
for hardware $ of time. Failure raises again as hardware 
components suffer from cumulative affects of 
environmental maladies (hardware wear 
.out) 
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Software is not susceptible to the environment 
maladies. Failure rate curve for software is as 
shown in figure. Undiscovered defects will cause 
high failures rates in the beginning of the 
program, these failures are corrected and the 
curve flattens. 

Actual curve Spikes in the curve is mainly due to some new 
defects. 
But software deteriorates due to change. 


FIGURE 1.2 


eal 


e Software is custom built rather than assembling existing components. 
Software applications: 


e System software: This class of software manages and controls the internal operations ofa 
computer system. It is a group of programs, which is responsible for using computer 
resources efficiently and effectively. For example, an operating system is a system software, 
which controls the hardware, manages memory and multitasking functions, and acts as an 
interface between application programs and the computer. 

Real-time software: This class of software observes, analyses, and controls real world 
events as they occur. Generally, a real-time system guarantees a response to an external 
event within a specified period of time. An example of real-time software is the software 
used for weather forecasting that collects and processes parameters like temperature and 
humidity from the external environment to forecast the weather. Most of the defence 
organizations all over the world use real-time software to control their military hardware. 
Business software: This class of software is widely used in areas where management and 
control of financial activities is of utmost importance. The fundamental component of a 
business system comprises payroll, inventory, and accounting software that permit the 
user to access relevant data from the database. These activities are usually performed with 
the help of specialized business software that facilitates efficient framework in business 
operations and in management decisions. 

Engineering and scientific software: This class of software has emerged as a powerful tool 
in the research and development of next generation technology. Applications such as the 
study of celestial bodies, under-surface activities, and programming of an orbital path for 
space shuttles are heavily dependent on engineering and scientific software. This software 
is designed to perform precise calculations on complex numerical data that are obtained 
during real-time environment. 

e Artificial intelligence (AI) software: This class of software is used where the problem- 
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solving technique is non-algorithmic in nature. The solutions of such problems are 
generally non-agreeable to computation or straightforward analysis. Instead, these 
problems require specific problem- solving strategies that include expert system, pattern 
recognition, and game- playing techniques. In addition, they involve different kinds of 
search techniques which include the use of heuristics. The role of artificial intelligence 
software is to add certain degrees of intelligence to the mechanical hardware in order to 
get the desired work done in an agile manner. 

Embedded Software : This type of software is embedded into the hardware normally in 
the Read-Only Memory (ROM) as a part of a large system and is used to support certain 
functionality under control conditions. 

Examples are software used in instrumentation and control applications like washing 
machines, satellites, microwaves, etc. 


Web-based software: This class of software acts as an interface between the user and the 
Internet. Data on the Internet is in the form of text, audio, or video format, linked with 
hyperlinks. Web browser is a software that retrieves web pages from the Internet. The 
software incorporates executable instructions written in special scripting languages such 
as CGI or ASP. Apart from providing navigation on the Web, this software also supports 
additional features that are useful while surfing the Internet. 

Personal computer (PC) software: This class of software is used for both official and 
personal use. The personal computer software market has grown over in the last two 
decades from normal text editor to word processor and from simple paintbrush to 


advanced image-editing software. This software is used predominantly in almost every 
field, whether it is database management system, financial accounting package, or 
multimedia-based software. It has emerged as a versatile tool for routine applications. 


Legacy Software 
Legacy software is an older program that are developed decades ago. The quality of legacy 
software is poor because it has inextensible design, convoluted code, poor and nonexistent 
documentation, test casesand results that are not achieved. 
As time passes legacy systems evolve due to following reasons: 
e The software must be adapted to meet the needs of new computing environment or 
technology. 
The software must be enhanced to implement new business requirements. 
The software must be extended to make it interoperable with more modern systems or 
database 
The software must be rearchitected to make it viable within a network environment. 


Unique nature of Web Apps 
The following attributes are encountered in the vast majority of WebApps. 


DEPT. OF ISE 


21CS61- Software Engineering and Project Management 


Network intensiveness. A WebApp resides on a network and must serve the needs of a diverse 
community of clients. The network may enable worldwide access and communication (i.e., the 
Internet) or more limited access and communication (e.g., a corporate Intranet). 
Concurrency: A large number of users may access the WebApp at one time. In many cases, the 
patterns of usage among end users will vary greatly. 
Unpredictable load: The number of users of the WebApp may vary by orders of magnitude from 
day to day. One hundred users may show up on Monday; 10,000 may use the system on Thursday. 
Performance: If a WebApp user must wait too long (for access, for server side processing, for 
client-side formatting and display), he or she may decide to go elsewhere. 
Availability: Although expectation of 100 percent availability is unreasonable, users of popular 
WebdApps often demand access on a 24/7/365 basis. Users in Australia or Asia might demand 
access during times when traditional domestic software applications in North America might be 
taken off-line for maintenance. 
Data driven: The primary function of many WebApps is to use hypermedia to present text, 
graphics, audio, and video content to the end user. In addition, WebApps are commonly used to 
access information that exists on databases that are not an integral part of the Web-based 
environment (e.g., e-commerce or financial applications). 
Content sensitive: The quality and aesthetic nature of content remains an important 
determinant of the quality of a WebApp. 
Continuous evolution: Unlike conventional application software that evolves over a series of 
planned, chronologically spaced releases, Web applications evolve continuously. It is not unusual 
for some WebApps (specifically, their content) to be updated on a minute-by-minute schedule or 
for content to be independently computed for each request. 
Immediacy: Although immediacy—the compelling need to get software to market quickly—is a 
characteristic of many application domains, WebApps often exhibit a time-to-market that can be 
a matter of a few days or weeks. 
Security: Because WebApps are available via network access, it is difficult, if not impossible, to 
limit the population of end users who may access the application. In order to protect sensitive 
content and provide secure modes of data transmission, strong security measures must be 
implemented throughout the infrastructure that supports a WebApp and within the application 
itself. 
Aesthetics: An undeniable part of the appeal of a WebApp is its look and feel. When an application 
has been designed to market or sell products or ideas, aesthetics may have as much to do with 
success as technical design. 
Software Engineering: 

e To build software that is ready to meet the current challenges, recognize a few simple 

realities: 

e Understand the problem before you build a solution 

e Design is a pivotal software engineering activity. 

e Both quality and maintainability are an outgrowth of good design 
Software Engineering - A Layered Technology 
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Quality focus - Bedrock that supports Software Engineering. 

Process - Foundation for software Engineering. Is the glue that 
holds technology layers together and enables rational and timely 
development of software. Process defines framework for a set of 
key process areas, which form the basis for management control 


Qualtty of Focus 


of software projects. 

Methods - Provide technical How-to’s for building software. Methods include requirement 
analysis, design, program construction, testing and support. 

Tools - Provide semi-automated and automated support to methods and process. 


A Process Framework 
e Establishes the foundation for a complete software process. 
e Identifies a number of framework activities applicable to all software projects. 
e Also include a set of umbrella activities that are applicable across the entire software 
process. 


Process framework determines the 
processes which are essential for 


Framework activities 
Task sets P 7 
completing a complex software project. 

This framework identifies certain activities, 

Milestones, deliverables known as framework activities, which are 

| applicable to all software projects regardless 


of their type and complexity. Some of the 

framework activities are listed below. 

e Communication: It involves 

communication with the user so that the 

requirements are easily understood. 

e Planning: It establishes a plan for 
accomplishing the project. It describes the schedule for the project, the technical tasks involved, 
expected risks, and the required resources. 

e Modeling: It encompasses creation of models, which allow the developer and the user to 
understand software requirements and the designs to achieve those requirements. 

e Construction: It combines generation of code with testing to uncover errors in the code. 

e Deployment: It implies that the final product (software) is delivered to the user. The user 
evaluates the delivered product and provides feedback based on the evaluation. 


Umbrella activities 


In addition to framework activities, process framework also comprises a set of activities 
known as umbrella activities, which are used throughout the software process. These activities 
are listed below. 
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Software project tracking and control: It monitors the actual process so that management can 
take necessary steps if the software project deviates from the plans laid down. It involves 
tracking procedures and reviews to check whether the software project is according to user’s 
requirements. A documented plan is used as a basis for tracking the software activities and 
revising the plans. 
Formal technical reviews: assesses software engineering work products in an effort to 
uncover and remove errors before they are propagated to the next activity. It assesses the 
code, products and documents of software engineering practices to detect and remove errors. 
Software quality assurance: Defines and conducts the activities required to ensure 
software quality. It assures that the software is according to the requirements. In addition, it 
is designed to evaluate the processes of developing and maintaining quality of the software. 
Reusability management: It determines the criteria for products’ reuse and establishes 
mechanisms to achieve reusable components. 
Software configuration management: It manages the changes made in the software 
processes of the products throughout the life cycle of the software project. It controls changes 
made to the configuration and maintains the integrity in the software development process. 
Risk management: Assesses risks that may affect the outcome of the project or the quality 
of the product. It identifies, analyzes, evaluates, and eliminates the possibility of unfavourable 
deviations from expected results, by following a systematic activityand then develops strategies 
to manage them. 
Measurement: Defines and collects process, project, and product measures that assist the 
team in delivering software that meets stakeholders’ needs; can be used in conjunction 
with all other framework and umbrella activities. 

e Work product preparation and production—encompasses the activities required to create 
work products such as models, documents, logs, forms, and lists. 


SOFTWARE ENGINEERING PRACTICE 

y Generic framework activities—communication, planning, modeling, construction, 
and deployment—and umbrella activities establish a skeleton architecture for 
software engineering work. 

The Essence of Practice : Essence of software engineering practice: 

Understand the problem (communication and analysis). 

Plan a solution (modeling and software design) 

Carry out the plan (code generation). 

Examine the result for accuracy (testing and quality assurance). 


. Understand the problem. It’s sometimes difficult to admit, but most of us suffer from 
hubris when we're presented with a problem. 
o Who has a stake in the solution to the problem? That is, who are the stakeholders? 
o What are the unknowns? What data, functions, and features are required to 
properly solve the problem? 
o Can the problem be compartmentalized? Is it possible to represent smaller 
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problems that may be easier to understand? 
o Can the problem be represented graphically? Can an analysis model be created? 

2. Plan the solution. Now you understand the problem (or so you think) and you can’t wait 
to begin coding. 

o Have you seen similar problems before? Are there patterns that are recognizable in 
a potential solution? Is there existing software that implements the data, functions, 
and features that are required? 

Has a similar problem been solved? If so, are elements of the solution reusable? 
Can subproblems be defined? If so, are solutions readily apparent for the 
subproblems? 

o Can you represent a solution in a manner that leads to effective implementation? 
Can a design model be created? 

3. Carry out the plan. The design you've created serves as a road map for the system you 
want to build. There may be unexpected detours, and it’s possible that you’ll discover an 
even better route as you go, but the “plan” will allow you to proceed without getting lost. 

o Does the solution conform to the plan? Is source code traceable to the design 
model? 

o Is each component part of the solution provably correct? Have the design and code 
been reviewed, or better, have correctness proofs been applied to the algorithm? 

4. Examine the result. You can’t be sure that your solution is perfect, but you can be sure 
that you've designed a sufficient number of tests to uncover as many errors as possible. 

o Isit possible to test each component part of the solution? Has a reasonable testing 
strategy been implemented? 

Does the solution produce results that conform to the data, functions, and features 
that are required? Has the software been validated against all stakeholder 
requirements? It shouldn’t surprise you that much of this approach is common 
sense. In fact, it’s reasonable to state that a commonsense approach to software 
engineering will never lead you astray. 
General Principles 
v The dictionary defines the word principle as “an important underlying law or 
assumption required in a system of thought.” David Hooker [Ho096] has proposed 
seven principles that focus on software engineering practice. They are reproduced in 
the following paragraphs: 

1) The First Principle: The Reason It All Exists 
A software system exists for one reason: to provide value to its users. All decisions should 

be made with this in mind. Before specifying a system requirement, before noting a piece of 
system functionality, before determining the hardware platforms or development processes, 
ask yourself questions such as: “Does this add real value to the system?” If the answer is “no,” 
don't do it. All other principles support this one. 

2) The Second Principle: KISS (Keep It Simple, Stupid!) 
yY Software design is not a haphazard process. There are many factors to consider in any 

design effort. All design should be as simple as possible, but no simpler. This facilitates 

having a more easily understood and easily maintained system. This is not to say that 
———— a a a ei 
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features, even internal features, should be discarded in the name of simplicity. Indeed, 
the more elegant designs are usually the more simple ones. Simple also does not mean 
“quick and dirty.’ In fact, it often takes a lot of thought and work over multiple iterations 
to simplify. The payoff is software that is more maintainable and less error-prone. 


3) The Third Principle: Maintain the Vision 


v 


A clear vision is essential to the success of a software project. Without one, a project 
almost unfailingly ends up being “of two [or more] minds” about itself. Without 
conceptual integrity, a system threatens to become a patchwork of incompatible 
designs, held together by the wrong kind of screws. Compromising the architectural 
vision of a software system weakens and will eventually break even the well-designed 
systems. Having an empowered architect who can hold the vision and enforce 
compliance helps ensure a very successful software project. 


4) The Fourth Principle: What You Produce, Others Will Consume 


v 


Seldom is an industrial-strength software system constructed and used in a vacuum. In 
some way or other, someone else will use, maintain, document, or otherwise depend 
on being able to understand your system. So, always specify, design, and implement 
knowing someone else will have to understand what you are doing. The audience for 
any product of software development is potentially large. Specify with an eye to the 
users. Design, keeping the implementers in mind. Code with concern for those that 
must maintain and extend the system. Someone may have to debug the code you write, 
and that makes them a user of your code. Making their job easier adds value to the 
system. 


5) The Fifth Principle: Be Open to the Future 


v 


A system with a long lifetime has more value. In today’s computing environments, 
where specifications change on a moment's notice and hardware platforms are 
obsolete just a few months old, software lifetimes are typically measured in months 
instead of years. However, true “industrial-strength” software systems must endure far 
longer. To do this successfully, these systems must be ready to adapt to these and other 
changes. Systems that do this successfully are those that have been designed this way 
from the start. Never design yourself into a corner. Always ask “what if,’ and prepare 
for all possible answers by creating systems that solve the general problem, not just 
the specific one. This could very possibly lead to the reuse of an entire system. 


6) The Sixth Principle: Plan Ahead for Reuse 


v 


Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal 
to accomplish in developing a software system. The reuse of code and designs has been 
proclaimed as a major benefit of using object-oriented technologies. However, the 
return on this investment is not automatic. To leverage the reuse possibilities that 
object-oriented [or conventional] programming provides requires forethought and 
planning. There are many techniques to realize reuse at every level of the system 
development process. ... Planning ahead for reuse reduces the cost and increases the 
value of both the reusable components and the systems into which they are 
incorporated. 


7) The Seventh principle: Think! 
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v 


This last principle is probably the most overlooked. Placing clear, complete thought 
before action almost always produces better results. When you think about something, 
you are more likely to do it right. You also gain knowledge about how to do it right 
again. 


SOFTWARE MYTHS 

Software myths—erroneous beliefs about software and the process that is used to build it— 
can be traced to the earliest days of computing. Myths have a number of attributes that make 
them insidious. For instance, they appear to be reasonable statements of fact (sometimes 
containing elements of truth), they have an intuitive feel, and they are often promulgated by 
experienced practitioners who “know the score.” 

Management myths. Managers with software responsibility, like managers in most 
disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and 
improve quality. Like a drowning person who grasps at a straw, a software manager often 
grasps at belief in a software myth, if that belief will lessen the pressure (even temporarily). 


v 


v 
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Myth: We already have a book that’s full of standards and procedures for building 
software. Won't that provide my people with everything they need to know? 
Reality: The book of standards may very well exist, but is it used? Are software 
practitioners aware of its existence? Does it reflect modern software 
engineering practice? Is it complete? Is it adaptable? Is it streamlined to 
improve time-to-delivery while still maintaining a focus on quality? In many 
cases, the answer to all these questions is“no.” 

Myth: If we get behind schedule, we can add more programmers and catch up 
(sometimes 

called the “Mongolian horde” concept). 

Reality: Software development is not a mechanistic process like statement may seem 
counterintuitive. However, as new people are added, people who were working must 
spend time educating the newcomers, thereby reducing the 

Reality: If an organization does not understand how to manage and control software 
projects 
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PROCESS MODEL 
A linear process flow executes each of the five framework activities in sequence, 
beginning with communication and culminating with deployment (Figure a). 
An iterative process flow repeats one or more of the activities before proceeding 
to the next (Figure b). 
An evolutionary process flow executes the activities in a “circular” manner. Each 
circuit through the five activities leads to a more complete version of the software 
(Figure c). 
A parallel process flow (Figure d) executes one or more activities in parallel with 
other activities (e.g., modeling for one aspect of the software might be executed in 
parallel with construction of another aspect of the software). 


— [cannon] - 


fo) linear process flow 


Communication 


idì Porolle! process flow 
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Defining a Framework Activity 
Software process 


Process framework v A software team would need significantly 


more information before it could properly 
execute any one of these activities as part of the 
software engineering action #1.1 software process. 

work tasks Y For a small software project requested by 


work products 
quality assurance points 


project eallectones one person (at a remote location) with simple, 
iin eccihisnaclicginclines GEE straightforward requirements, the 
work take communication activity might encompass 
sr Arar poieni little more than a phone call with the 
appropriate stakeholder. Therefore, the only 
necessary action is phone conversation, and the 
framework activity # n work tasks (the task set) that this action 
software engineering action #n.1 encompasses are: 
Tosk sos |) Were a 1. Make contact with stakeholder via telephone. 
sues om 2. Discuss requirements and take notes. 
software engineering action #n.m 3. Organize notes into a brief written statement 
work products of requirements. 
proies mienens: 4. E-mail to stakeholder for review and approval. 
v If the project was considerably more 
complex with many stakeholders, each with a 
different set of (sometime conflicting) requirements, the communication activity might 
have six distinct actions : inception, elicitation, elaboration, negotiation, specification, 
and validation. 
Identifying a Task Set 
v Referring again to Figure 2.1, each software engineering action (e.g., elicitation, an 
action associated with the communication activity) can be represented by a number of 
different task sets—each a collection of software engineering work tasks, related work 
products, quality assurance points, and project milestones. You should choose a task 
set that best accommodates the needs of the project and the characteristics of your 
team. This implies that a software engineering action can be adapted to the specific 
needs of the software project and the characteristics of the project team. 


Umbrella activities 


framework activity # 1 


Task sets 


Task sets 


Process Patterns 

A process pattern describes a process-related problem that is encountered during software 
engineering work, identifies the environment in which the problem has been encountered, and 
suggests one or more proven solutions to the problem. Stated in more general terms, a process 
pattern provides you with a template —a consistent method for describing problem solutions 
within the context of the software process. 

Patterns can be defined at any level of abstraction. 

a pattern might be used to describe a problem (and solution) associated with a complete process 
model (e.g., prototyping). 
eee Sat 
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patterns can be used to describe a problem (and solution) associated with a framework activity 
(e.g., planning) or an action within a framework activity (e.g., project estimating). 

Ambler has proposed a template for describing a process pattern: 

Pattern Name. The pattern is given a meaningful name describing it within the context of the 
software process (e.g., Technical Reviews). 

Forces. The environment in which the pattern is encountered and the issues that make the 
problem visible and may affect its solution. 

Type. The pattern type is specified. Ambler suggests three types: 

1. Stage pattern—defines a problem associated with a framework activity for the process. Since 
a framework activity encompasses multiple actions and work tasks, a stage pattern 
incorporates multiple task patterns (see the following) that are relevant to the stage 
(framework activity). An example of a 

stage pattern might be Establishing Communication. This pattern would incorporate the task 
pattern Requirements Gathering and others. 

2. Task pattern—defines a problem associated with a software engineering action or work task 
and relevant to successful software engineering practice (e.g, Requirements Gathering is a 
task pattern). 

3. Phase pattern—define the sequence of framework activities that occurs within the process, 
even when the overall flow of activities is iterative in nature. An example of a phase pattern 
might be Spiral Model or Prototyping. 


Initial context. Describes the conditions under which the pattern applies. Prior to the initiation 
of the pattern: 

(1) What organizational or team-related activities have already occurred? 

(2) What is the entry state for the process? 

(3) What software engineering information or project information already exists? 

For example, the Planning pattern (a stage pattern) requires that 

(1) customers and software engineers have established a collaborative communication; 

(2) successful completion of a number of task patterns [specified] for the Communication 
pattern has occurred; and 

(3) the project scope, basic business requirements, and project constraints are known. 
Problem. The specific problem to be solved by the pattern. 

Solution. Describes how to implement the pattern successfully. This section describes how the 
initial state of the process (that exists before the pattern is implemented) is modified as a 
consequence of the initiation of the pattern. It also describes how software engineering 
information or project information that is available before the initiation of the pattern is 
transformed as a consequence of the successful execution of the pattern. 

Resulting Context. Describes the conditions that will result once the pattern has been 
successfully implemented. Upon completion of the pattern: 

(1) What organizational or team-related activities must have occurred? 

(2) What is the exit state for the process? 

(3) What software engineering information or project information has been developed? 
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Related Patterns. Provide a list of all process patterns that are directly related to this one. This 
may be represented as a hierarchy or in some other diagrammatic form. For example, the stage 
pattern Communication encompasses the task patterns: Project Team, Collaborative 
Guidelines, Scope Isolation, Requirements Gathering, Constraint Description, and 
Scenario Creation. 

Known Uses and Examples. Indicate the specific instances in which the pattern is applicable. 
For example, Communication is mandatory at the beginning of every software project, is 
recommended throughout the software project, and is mandatory once the deployment activity 
is under way. 

Process patterns provide an effective mechanism for addressing problems associated with any 
software process. The patterns enable you to develop a hierarchical process description that 
begins at a high level of abstraction (a phase pattern). The description is then refined into a set 
of stage patterns that describe framework activities and are further refined in a hierarchical 
fashion into more detailed task 

patterns for each stage pattern. Once process patterns have been developed, they can be reused 
for the definition of process variants—that is, a customized process model can be defined by a 
software team using the patterns as building blocks for the process model. 


An Example Process Pattern 

The following abbreviated process pattern 

describes an approach that may be applicable 
when stakeholders have a general idea of what must be 
done but are unsure of specific software requirements. 


Pattern name, RequirementsUnclear 


Intent. This pattern describes on approach for building o 
model (a prototype) that can be assessed iteratively by 
stakeholders in an offort to identify or solidity software 


requiroments 


Type. Phase pattern 


Initial context. The following conditions must be met 
prior to the initiation of this pattern: (1) stakeholders have 
been identified; (2) a mode of communication between 
stakeholders and the soltware team has been established; 
(3) the overriding software problem to be solved has been 
identified by stakeholders; (4) an initial understanding of 
project scope, basic business requirements, and project 
constraints has been developed 


Problem. Requirements are hazy or nonexistent, yet 
there is clear recognition that there is a problem to be 


solved, and the problem must be addressed with a 
software solution. Stakeholders are unsure of what they 
want; that is, they cannot describe software requirements 
in any detail 


Solution. A description of the prototyping process 
would be prasented here and is described later in 
Section 2.3.3. 


Resulting context, A software prototype that identifies 
basic requirements (e.g., modes of interaction, 
computational features, processing functions) is approved 
by stakeholders. Follawing this, (1) the prototype may 
evolve through a series of increments to become the 
production software or (2) the prototype maoy be discarded 
and the production software built using some other process 
pattern 

Related patterns. The following patterns are related te 
this pattern. CustomerCommunication, 
HterativeDesign, lterativeDevelopment, 
CustomerAssessment, RequirementExtraction, 
Known uses and examples, Prototyping is 


recommended when requitements are uncertain 


Process Assessment and Improvement 

A number of different approaches to software process assessment and improvement have been 
proposed over the past few decades: 

Standard CMMI Assessment Method for Process Improvement 

(SCAMPI)—provides a five-step process assessment model that incorporates five phases: 
initiating, diagnosing, establishing, acting, and learning. The SCAMPI method uses the SEI CMMI 
as the basis for assessment [SEI00]. 

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)— 

provides a diagnostic technique for assessing the relative maturity of a software organization; 
uses the SEI CMM as the basis for the assessment. 


DEPT. OF ISE 


21CS61- Software Engineering and Project Management 


SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process 
assessment. The intent of the standard is to assist organizations in developing an objective 
evaluation of the efficacy of any defined software process. 
ISO 9001:2000 for Software—a generic standard that applies to any organization that wants 
to improve the overall quality of the products, systems, or services that it provides. Therefore, 
the standard is directly applicable to software organizations and companies. 


PROCESS MODELS 

PRESCRIPTIVE PROCESS MODELS 

Prescriptive process models were initially designed to bring structure to software development, 
but the nature of software work and its products often resides in a state between order and 
chaos known as "the edge of chaos." This state allows for creativity and self-organization while 
maintaining some level of structure necessary for change. While traditional models prioritize 
order, they may not suit the dynamic nature of software development. However, abandoning 
structure entirely could lead to coordination and coherence issues. Finding the right balance is 
crucial, and various alternatives exist for software engineers to explore. These models prescribe 
a set of process elements and a process flow, each emphasizing different activities and 
approaches to achieving project consistency. 


The Waterfall Model 
There are instances when the needs for a problem are clear—when workflows from 
communication to deployment in a somewhat linear manner. 

Context: Used when requirements are reasonably well understood. 
Advantage: It can serve as a useful process model in situations where requirements are fixed 
and work is to proceed to complete in a linear manner. 


The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential 
approach to software development that begins with customer specification of requirements and 
progresses through planning, modeling, construction, and deployment, culminating in ongoing 
support of the completed software (Figure 2.3). 


The waterfall model 


—| Communication pl . 
project Initiation ona J Modeli 
requirements gothari estimating iad 
equirements gathering scheduling analysis a Deployment 
tracking design elivery 
support 


feedbock 
The problems that are sometimes encountered when the waterfall model is applied are: 
1. Real projects rarely follow the sequential flow that the model proposes. 
Although the linear model can accommodate iteration, it does so 
indirectly. As a result, changes can cause confusion as the project team 
proceeds. 
2. Itis often difficult for the customer to state all requirements explicitly. 
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The waterfall model requires this and has difficulty accommodating the 
natural uncertainty that exist at the beginning of many projects. 

The customer must have patience. A working version of the programs 
will not be available until late in the project time-span. If a major blunder 
is undetected then it can be disastrous until the program is reviewed. 


A variation in the representation of the waterfall 
model is called the V-model. Represented in Figure 
2.4, the V-model depicts the relationship of quality 
assurance actions to the actions associated with 
communication, modeling, and early construction 
activities. As a software team moves down the left 
side of the V, basic problem requirements are refined 
into progressively more detailed and technical 
representations of the problem and its solution. Once 
code has been generated, the team moves up the right 
side of the V, essentially performing a series of tests 
breccia (quality assurance actions) that validate each of the 
ae models created as the team moved down the left side. 
In reality, there is no fundamental difference between the classic life cycle and the V-model. The 
V-model provides a way of visualizing how verification and validation actions are applied to 
earlier engineering work. The waterfall model is the oldest paradigm for software engineering. 
However, criticism of this process model has caused even ardent supporters to question its 
efficacy. 
Today, software work is fast-paced and subject to a never-ending stream of changes (to features, 
functions, and information content). The waterfall model is often inappropriate for such work. 
However, it can serve as a useful process model in situations where requirements are fixed and 
work is to proceed to completion in a linear manner. 
Incremental Process Models 
Context: Incremental development is particularly useful when staffing is unavailable for a 
complete implementation by the business deadline that has been established for the project. 
Early increments can be implemented with fewer people. If the core product is well received, 
additional staff can be added to implement the next increment. The incremental model 
combines elements of linear and parallel process flows. Referring to Figure 2.5, the 
incremental model applies linear sequences in a staggered fashion as calendar time 
progresses. Each linear sequence produces deliverable “increments” of the software. 
When an incremental model is used, the first increment is often a core product. That is, basic 
requirements are addressed but many supplementary features (some known, others unknown) 
remain undelivered. The core product is used by the customer (or undergoes detailed 
evaluation). 
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[_] Communication The incremental process 
[] Pronning model focuses on the 
[Eo] Moding flys, desig) — sr delivery of an operational 
product with each 
increment. Early 
pees ere increments are stripped- 
down versions of the final 
deivary of product, but they do 
Serine provide capability that 
serves the user and also 
provide a platform for 
evaluation by the user. 
Incremental development 
is particularly useful when: 
e staffing is unavailable for a complete implementation by the business deadline that has 
been established for the project. Early increments can be implemented with fewer people. 
If the core product is well received, then additional staff (if required) can be added to 
implement the next increment. 
e increments can be planned to manage technical risks. 
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Evolutionary Process Models 


Software, like all complex systems, evolves over a period of time. In these situations, the process 
model has to be explicitly designed to accommodate a product that evolves over time. 
Evolutionary models are iterative. They are characterized in a manner that enables you to 
develop increasingly more complete versions of the software. Two common evolutionary process 
models. 


Prototyping: Prototyping is most 


frequently employed as a technique that 

= may be applied in conjunction with any of 

Moat the process models mentioned earlier, 

Quick desian J however it can also be used as a stand- 

alone process model. Regardless of the 

manner in which it is applied, the 

prototyping paradigm assists you and 

Cy Construction other stakeholders to better understand 

prototype what is to be built when requirements are 

fuzzy. 

The first step in the prototype paradigm 

(Figure is communication. Meet with other stakeholders to define the overall objectives for the 

software, identify whatever requirements are known, and outline areas where further definition 

is mandatory. A prototyping iteration is planned quickly, and modeling (in the form of a “quick 

design”) occurs. A quick design focuses on a representation of those aspects of the software that 
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will be visible to end users (e.g., human interface layout or output display formats). The quick 
design leads to the construction of a prototype. The prototype is deployed and evaluated by 
stakeholders, who provide feedback that is used to further refine requirements. 

Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at 
the same time enabling you to better understand what needs to be done. Ideally, the prototype 
serves as a mechanism for identifying software requirements. 

The prototype paradigm is popular with software engineers as well as stakeholders. 

Developers can start working on anything right away, while users receive a sense of the real syst 
em. However, the following factors make prototyping potentially problematic: 

1. Stakeholders witness what seems to be a functional version of the software; they are unaware 
that the prototype is loosely put together and that longterm maintainability and overall software 
quality wereneglected in the haste to get it operating.Few "fixes" to make the prototype a functio 
nal product in 

what stakeholders demand when they are told that the product must be rebuilt in order to 
maintain high standards of quality. 

2. In order to quickly get a prototype operating, software engineers frequently have to make 
implementation concessions. Because it is readily available and well-known, an improper 
operating system or programming language may be employed; an ineffective algorithm may be 
built merely to show off its capabilities. The choice that wasn't perfect has now become a 
necessary component of the system. 


The Spiral Model. 


The spiral model, which was first put 

Plonning forth by Barry Boehm [Boe88], is an 

eR PD evolutionary software process model that 
scheduling 

risk analysis combines the waterfall model's regulated 


and methodical features with the iterative 


nature of prototyping. It offers the 
mones possibility of quickly developing 
design progressively more comprehensive 
software versions. The model is 
described by Boehm [Boe01a] as follows: 
The spiral development model is a risk- 
driven process model generator that is 
used to guide multi-stakeholder 
concurrent engineering of software 
intensive systems. 
It has two main distinguishing features. 
One is a cyclic approach for incrementally growing a system’s degree of definition and 
implementation while decreasing its degree of risk. 
The other is a set of anchor point milestones for ensuring stakeholder commitment to 
feasible and mutually satisfactory system solutions. Using the spiral model, software is 
developed in a series of evolutionary releases. During early iterations, the release might 
a R) 
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be a model or prototype. During later iterations, increasingly more complete versions of 
the engineered system are produced. 
A spiral model is divided into a set of framework activities defined by the software 
engineering team. Each of the framework activities represent one segment of the spiral 
path illustrated in Figure. As this evolutionary process begins, the software team performs 
activities that are implied by a circuit around the spiral in a clockwise direction, beginning 
at the center. Risk is considered as each revolution is made. Anchor point milestones—a 
combination of work products and conditions that are attained along the path of the 
spiral—are noted for each evolutionary pass. 
Draw Backs: 
The spiral model is not a panacea. It may be difficult to convince customers that the 
evolutionary approach is controllable. It demands considerable risk assessment expertise 
and relies on this expertise for success. If a major risk is not uncovered and managed, 
problems will undoubtedly occur. 


THE CONCURRENT DEVELOPMENT MODEL 


e The concurrent development model also called 
concurrent engineering 

e Constitutes a series of framework activities, 
software engineering action, tasks and their 
associated states 

e All activities exist concurrently but reside in 
different states 

e Applicable to all types of software development 

e Event generated at one point in the process trigger 
transitions among the states. 


SPECIALIZED PROCESS MODELS 


These models tend to be applied when a specialized or narrowly defined software engineering 
approach is chosen. 


Component-Based Development: Commercial off-the-shelf (COTS) software components, 
developed by vendors who offer them as products, provide targeted functionality with well- 
defined interfaces that enable the component to be integrated into the software that is to be 
built. The component-based development model incorporates many of the characteristics of 
the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation 
of software. However, the component-based development model constructs applications from 
prepackaged software components. 
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Modeling and construction activities begin with the identification of candidate components. 
These components can be designed as either conventional software modules or object- 
oriented classes or packages of classes. Regardless of the technology that is used to create the 
components, the component-based development model incorporates the following steps 


Available component-based products are researched and evaluated for the application 
domain in question. 

Component integration issues are considered. 

A software architecture is designed to accommodate the components. 

Components are integrated into the architecture. 

Comprehensive testing is conducted to ensure proper functionality. 


The component-based development model leads to software reuse, and reusability provides 
software engineers with a number of measurable benefits. 


The Formal Methods Model: The formal methods model encompasses a set of activities that 
leads to formal mathematical specification of computer software. Formal methods enable you 
to specify, develop, and verify a computer-based system by applying a rigorous, mathematical 
notation. A variation on this approach, called cleanroom software engineering, is currently 
applied by some software development organizations. 


When formal methods are used during design, they serve as a basis for program verification 
and therefore enable you to discover and correct errors that might otherwise go undetected. 
Although not a mainstream approach, the formal methods model offers the promise of defect- 
free software. Yet, concern about its applicability in a business environment has been voiced: 
e The development of formal models is currently quite time consuming and 
expensive. 
Because few software developers have the necessary background to apply 
formal methods, extensive training is required. 
It is difficult to use the models as a communication mechanism for technically 
unsophisticated customers. 


Aspect-Oriented Software Development:Regardless of the software process that is chosen, 
the builders of complex software invariably implement a set of localized features, functions, 
and information content. These localized software characteristics are modeled as components 
(e.g., object oriented classes) and then constructed within the context of a system architecture. 


As modern computer-based systems become more sophisticated (and complex), Other 
concerns affect functions (e.g., the application of business rules), while others are systemic 
(e.g., task synchronization or memory management). 
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When concerns cut across multiple system functions, features, and information, they are often 
referred to as crosscutting concerns. Aspectual requirements define those crosscutting 
concerns that have an impact across the software architecture. Aspect- oriented software 
development (AOSD), often referred to as aspect-oriented programming (AOP), is a relatively 
new software engineering paradigm that provides a process and methodological approach for 
defining, specifying, designing, and constructing aspects. 


AOCE uses a concept of horizontal slices through vertically-decomposed software components, 
called “aspects,” to characterize cross-cutting functional and non- functional properties of 
components. Common, systemic aspects include user interfaces, collaborative work, distribution, 
persistency, memory management, transaction processing, security, integrity and so on 
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Module - II 


Understanding Requirements: Requirements Engineering, Establishing the ground work, 
Eliciting Requirements, Developing use cases, Building the requirements model, 
Negotiating 

Requirements, Validating Requirements 

Textbook 1: Chapter 5: 5.1 to 5.7 

Requirements Modeling Scenarios, Information and Analysis classes: Requirement 
Analysis, 

Scenario based modeling, UML models that supplement the Use Case, Data modeling 
Concepts class 

Based Modeling. 

Textbook 1: Chapter 6: 6.1 to 6.5 
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REQUIREMENTS ENGINEERING 


The broad spectrum of tasks and techniques that lead to an understanding of 
requirements is called requirements engineering. From a software process perspective, 
requirements engineering is a major software engineering action that begins during the 
communication activity and continues into the modeling activity. It must be adapted to the 
needs of the process, the project, the product, and the people doing the work. 


Requirements engineering builds a bridge to design and construction. Requirements 
engineering provides the appropriate mechanism for understanding what the customer 
wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying 
the solution unambiguously, validating the specification, and managing the requirements 
as they are transformed into an operational system. It encompasses seven distinct tasks: 
inception, elicitation, elaboration, negotiation, specification, validation, and 
management. 

a) Inception. In general, most projects begin when a business need is identified or a potential 
new market or service is discovered. Stakeholders from the business community define a 
business case for the idea, try to identify the breadth and depth of the market, do a rough 
feasibility analysis, and identify a working description of the project’s scope. 

At project inception, you establish a basic understanding of the problem, the people who 
want a solution, the nature of the solution that is desired, and the effectiveness of 
preliminary communication and collaboration between the other stakeholders and the 
software team. 


b) Elicitation. Ask the customer, what the objectives for the system or product are, what is to be 
accomplished, how the system or product fits into the needs of the business, and finally, how 
the system or product is to be used on a day-to-day basis. A number of problems that are 
encountered as elicitation occurs. 

Problems of scope. The boundary of the system is ill-defined or the customers/users specify 
unnecessary technical detail that may confuse, rather than clarify, overall system objectives. 
Problems of understanding. The customers/users are not completely sure of what is 
needed, have a poor understanding of the capabilities and limitations of their computing 
environment, don’t have a full understanding of the problem domain, have trouble 
communicating needs to the system engineer, omit information that is believed to be 
“obvious,” specify requirements that conflict with the needs of other customers/users, or 
specify requirements that are ambiguous or un testable. 

Problems of volatility. The requirements change over time. To help overcome these 
problems, you must approach requirements gathering in an organized manner. 


Elaboration. The information obtained from the customer during inception and elicitation is 
expanded and refined during elaboration. This task focuses on developing a refined 
requirements model that identifies various aspects of software function, behavior, and 
information. 
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Elaboration is driven by the creation and refinement of user scenarios that describe how 
the end user (and other actors) will interact with the system. Each user scenario is parsed 
to extract analysis classes—business domain entities that are visible to the end user. The 
attributes of each analysis class are defined, and the services that are required by each 
class are identified. The relationships and collaboration between classes are identified, 
and a variety of supplementary diagrams are produced. 


d) Negotiation. It usual for customers, to given limited business resources. It’s also relatively 
common for different customers or users to propose conflicting requirements, arguing that 
their version is “essential for our special needs.” 

You have to reconcile these conflicts through a process of negotiation. Customers, users, 
and other stakeholders are asked to rank requirements and then discuss conflicts 

in priority. Using an iterative approach that prioritizes requirements, assesses their cost 
and risk, and addresses internal conflicts, requirements are eliminated, combined, and/or 
modified so that each party achieves some measure of satisfaction. 


e) Specification. Specification means different things to different people. A specification can be 
a written document, a set of graphical models, a formal mathematical model, a collection of 
usage scenarios, a prototype, or any combination of these. Some suggest that a “standard 
template” should be developed and used for a specifcation, arguing that this leads to 
requirements that are presented in a consistent and therefore more understandable manner. 
However, it is sometimes necessary to remain flexible when a specification is to be developed. 
For large systems, a written document, combining natural language descriptions and 
graphical models may be the best approach. 


ESTABLISHING THE GROUNDWORK 


In an ideal setting, stakeholders and software engineers work together on the same team. 
In such cases, requirements engineering is simply a matter of conducting meaningful 
conversations with colleagues who are well-known members of the team. 


We discuss the steps required to establish the groundwork for an understanding of 
software requirements—to get the project started in a way that will keep it moving 
forward toward a successful solution. 


Identifying Stakeholders: Stakeholder is “anyone who benefits in a direct or indirect way 
from the system which is being developed.” The usual stakeholders are: business operations 
managers, product managers, marketing people, internal and external customers, end users, 
consultants, product engineers, software engineers, support and maintenance engineers. Each 
stakeholder has a different view of the system, achieves different benefits when the system is 
successfully developed, and is open to different risks if the development effort should fail. 


Recognizing Multiple Viewpoints: Because many different stakeholders exist, the 
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requirements of the system will be explored from many different points of view. Each of these 
constituencies will contribute information to the requirements engineering process. As 
information from multiple viewpoints is collected, emerging requirements may be 
inconsistent or may conflict with one another. You should categorize all stakeholder 
information in a way that will allow decision makers to choose an internally consistent set of 
requirements for the system. 

Working toward Collaboration: If five stakeholders are involved in a software project, you 
may have five different opinions about the proper set of requirements. Customers must 
collaborate among themselves and with software engineering practitioners if a successful 
system is to result. The job of a requirements engineer is to identify areas of commonality and 
areas of conflict or inconsistency. Collaboration does not necessarily mean that requirements 
are defined by committee. In many cases, stakeholders collaborate by providing their view of 
requirements, but a strong “project champion” may make the final decision about which 
requirements make the cut. 


Asking the First Questions: Questions asked at the inception of the project should be 
“context free. The first set of context-free questions focuses on the customer and other 
stakeholders, the overall project goals and benefits. You might ask: 
e Who is behind the request for this work? 
e Who will use the solution? 
e What will be the economic benefit of a successful solution? 
e Is there another source for the solution that you need? 
These questions help to identify all stakeholders who will have interest in the software to 
be built. In addition, the questions identify the measurable benefit of a successful 
implementation and possible alternatives to custom software development. 
The next set of questions enables you to gain a better understanding of the problem and 
allows the customer to voice his or her perceptions about a solution: 
e How would you characterize “good” output that would be generated by a successful solution? 
e What problem(s) will this solution address? 
e Can you show me (or describe) the business environment in which the solution will be used? 
e Will special performance issues or constraints affect the way the solution is approached? 
The final set of questions focuses on the effectiveness of the communication activity itself. 
e Are you the right person to answer these questions? Are your answers “official”? 
e Are my questions relevant to the problem that you have? 
e Am I asking too many questions? 
e Can anyone else provide additional information? 
e Should I be asking you anything else? 
These questions will help to “break the ice” and initiate the communication that is 
essential to successful elicitation. 


ELICITING REQUIREMENTS 


Requirements elicitation combines elements of problem solving, elaboration, negotiation, 
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and specification. 

Collaborative Requirements Gathering: Many different approaches to collaborative 
requirements gathering have been proposed. 

e Meetings are conducted and attended by both software engineers and other stakeholders. 

e Rules for preparation and participation are established. 

e An agenda is suggested that is formal enough to cover all important points but informal 
enough to encourage the free flow of ideas. 

e A “facilitator” controls the meeting. 

e A “definition mechanism” (can be work sheets, flip charts etc) is used. 


The goal is to identify the problem, propose elements of the solution, negotiate different 
approaches, and specify a preliminary set of solution requirements in an atmosphere that 
is conducive to the accomplishment of the goal. 


While reviewing the product request in the days before the meeting, each attendee is 
asked to make a list of objects that are part of the environment that surrounds the system, 
other objects that are to be produced by the system, and objects that are used by the 
system to perform its functions. 


The mini-specs are presented to all stakeholders for discussion. Additions, deletions, and 
further elaboration are made. In some cases, the development of mini-specs will uncover 
new objects, services, constraints, or performance requirements that will be added to the 
original lists. During all discussions, the team may raise an issue that cannot be resolved 
during the meeting. An issues list is maintained so that these ideas will be acted on later. 


Quality Function Deployment: Quality function deployment (QFD) is a quality management 
technique that translates the needs of the customer into technical requirements for software. 
QFD “concentrates on maximizing customer satisfaction from the software engineering 
process”. QFD identifies three types of requirements: 
Normal requirements. The objectives and goals that are stated for a product or system 
during meetings with the customer. If these requirements are present, the customer is 
satisfied. 
Examples of normal requirements might be requested types of graphical displays, specific 
system functions, and defined levels of performance. 
Expected requirements. These requirements are implicit to the product or system and 
may be so fundamental that the customer does not explicitly state them. Their absence 
will be a cause for significant dissatisfaction. Examples of expected requirements are: ease 
of human/machine interaction, overall operational correctness and reliability, and ease of 
software installation. 
Exciting requirements. These features go beyond the customer’s expectations and prove 
to be very satisfying when present. For example, software for a new mobile phone comes 
with standard features, but is coupled with a set of unexpected capabilities (e.g. 
multitouch screen, visual voice mail) that delight every user of the product. 
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Usage Scenarios: As requirements are gathered, an overall vision of system functions and 
features begins to materialize. However, it is difficult to move into more technical software 
engineering activities until you understand how these functions and features will be used by 
different classes of end users. To accomplish this, developers and users can create a set of 
scenarios that identify a thread of usage for the system to be constructed. 


Elicitation Work Products: The work products produced as a consequence of requirements 
elicitation will vary depending on the size of the system or product to be built. For most 
systems, the work products include 
e A statement of need and feasibility. 
° A bounded statement of scope for the system or product. 
e A list of customers, users, and other stakeholders who participated in requirements 
elicitation. 
e A description of the system’s technical environment. 
e A list of requirements and the domain constraints that apply to each. 
e A set of usage scenarios that provide insight into the use of the system or product under 
different operating conditions. 
e Any prototypes developed to better define requirements. 
Each of these work products is reviewed by all people who have participated in 
requirements elicitation. 


DEVELOPING USE CASES 


In essence, a use case tells a stylized story about how an end user interacts with the system 
under a specific set of circumstances. The story may be narrative text, an outline of tasks 
or interactions, a template-based description, or a diagrammatic representation. 
Regardless of its form, a use case depicts the software or system from the end user’s point 
of view. 


The first step in writing a use case is to define the set of “actors” that will be involved in 
the story. Actors are the different people (or devices) that use the system or product 
within the context of the function and behavior that is to be described. It is important to 
note that an actor and an end user are not necessarily the same thing. It is possible to 
identify primary actors during the first iteration and secondary actors as more is learned 
about the system. 
Primary actors interact to achieve required system function and derive the intended 
benefit from the system. They work directly and frequently with the software. Secondary 
actors support the system so that primary actors can do their work. 
Once actors have been identified, use cases can be developed. Jacobson suggests a number 
of questions that should be answered by a use case: 

e Who is the primary actor, the secondary actor(s)? 

e What are the actor’s goals? 
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e What preconditions should exist before the story begins? 

e What main tasks or functions are performed by the actor? 

e What exceptions might be considered as the story is described? 

e What variations in the actor’s interaction are possible? 

e What system information will the actor acquire, produce, or change? 

e Will the actor have to inform the system about changes in the external environment? 
e What information does the actor desire from the system? 

e Does the actor wish to be informed about unexpected changes? 


BUILDING THE REQUIREMENTS MODEL 


Fig 5.2: UML use case diagram for safe home security function Different modes of representation force you to 


The intent of the analysis model is to provide a 
description of the required informational, 
functional, and behavioral domains for a 
computer-based system. The model changes 
dynamically as you learn more about the 
system to be built, and other stakeholders 
understand 


more about what they really require. For that 
reason, the analysis model is a snapshot of 
requirements at any given time. 


Elements of the Requirements Model: There 
are many different ways to look at the 
requirements for a computer-based system. 
from different 


consider requirements 


viewpoints—an approach that has a higher probability of uncovering omissions, 


inconsistencies, and ambiguity. 
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Scenario-based elements. The system is described from the user’s point of view using a 
scenario-based approach. For example, basic use cases and their corresponding use-case 
diagrams evolve into more elaborate template-based use cases. Scenario-based elements 


„ù Conduct 
; meetings 


Make lists of 
functions, classes 


Formal prioritization? 
Yes No 


ye Define 
(Use QFD to Informally Pi POLRES 
prioritize prioritize Ea 
F Write 
scenario 


Complete 
template 


Fig 5.3: UML activity diagrams for Eliciting ~~~. @ 
of the requirements model are often the first part of the model that is developed. Three 
levels of elaboration are shown, culminating in a scenario-based representation. 


| Elicit requirements 


Class-based elements. Each usage scenario implies a set 
of objects that are manipulated as an actor interacts with 
the system. These objects are categorized into classes—a 
collection of things that have similar attributes and 
common behaviors. Example shown in figure. 


Fig 5.4: Class diagram for sensor 


Behavioral elements. The behavior of a computer-based system can have a profound 
effect on the design that is chosen and the implementation approach that is applied. 
Therefore, the requirements model must provide modeling elements that depict behavior. 
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The state diagram is one method for representing the behavior of a system by depicting 
its states and the events that cause the system to change state. A state is any externally 
observable mode of behavior. In addition, the state diagram indicates actions taken as a 
consequence of a particular event. 


™ State name 
System status = "Ready" 
Display msg = "enter cmd" 
Display status = steady 


State variables 


Eniry/subsystems ready 

Do: poll user input panel - State activities 
Do: read user input 

Do: interpret user input 


Fig 5.5: UML State diagram notation 


Flow-oriented elements. Information is transformed as it flows through a computer- 
based system. The system accepts input in a variety of forms, applies functions to 
transform it, and produces output in a variety of forms. Input may be a control signal 
transmitted by a transducer, a series of numbers typed by a human operator, a packet of 
information transmitted on a network link, or a voluminous data file retrieved from 
secondary storage. The transform(s) may comprise a single logical comparison, a complex 
numerical algorithm, or a rule-inference approach of an expert system. 


Analysis Patterns: Anyone who has done requirements engineering on more than a few 
software projects begins to notice that certain problems reoccur across all projects within a 
specific application domain. These analysis patterns suggest solutions (e.g., a class, a function, 
a behavior) within the application domain that can be reused when modeling many 
applications. Analysis patterns are integrated into the analysis model by reference to the 
pattern name. They are also stored in a repository so that requirements engineers can use 
search facilities to find and apply them. Information about an analysis pattern (and other 
types of patterns) is presented in a standard template. 


NEGOTIATING REQUIREMENTS 
In an ideal requirements engineering context, the inception, elicitation, and elaboration 
tasks determine customer requirements in sufficient detail to proceed to subsequent 
software engineering activities. You may have to enter into a negotiation with one or more 
stakeholders. In most cases, stakeholders are asked to balance functionality, performance, 
and other product or system characteristics against cost and time-to-market. The intent 
of this negotiation is to develop a project plan that meets stakeholder needs while at the 
same time reflecting the real- world constraints (e.g., time, people, budget) that have been 
placed on the software team. 
The best negotiations strive for a “win-win” result. That is, stakeholders win by getting the 
system or product that satisfies the majority of their needs and you win by working to 
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realistic and achievable budgets and deadlines. 
Boehm [Boe98] defines a set of negotiation activities at the beginning of each software 
process iteration. Rather than a single customer communication activity, the following 
activities are defined: 

1. Identification of the system or subsystem’s key stakeholders. 

2. Determination of the stakeholders’ “win conditions.” 

3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win 

conditions for all concerned. 


VALIDATING REQUIREMENTS 
As each element of the requirements model is created, it is examined for inconsistency, 
omissions, and ambiguity. The requirements represented by the model are prioritized by 
the stakeholders and grouped within requirements packages that will be implemented as 
software increments. A review of the requirements model addresses the following 
questions: 
e Is each requirement consistent with the overall objectives for the system/product? 
e Have all requirements been specified at the proper level of abstraction? That is, do some 
requirements provide a level of technical detail that is inappropriate at this stage? 
e Is the requirement really necessary or does it represent an add-on feature that may not be 
essential to the objective of the system? 
e Is each requirement bounded and unambiguous? 
e Does each requirement have attribution? That is, is a source noted for each requirement? 
e Do any requirements conflict with other requirements? 
e Is each requirement achievable in the technical environment that will house the system or 
product? 
e Is each requirement testable, once implemented? 
* Does the requirements model properly reflect the information, function, and behavior of the 
system to be built? 
e Has the requirements model been “partitioned” in a way that exposes progressively more 
detailed information about the system? 
e Have requirements patterns been used to simplify the requirements model? 
Have all patterns been properly validated? Are all patterns consistent with customer 
requirements? 
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Requirements Modeling (Scenarios, Information and Analysis Classes) 


What is it? The written word is a wonderful vehicle for communication, but it is not 
necessarily the best way to represent the requirements for computer software. 
Requirements modeling uses a combination of text and diagrammatic forms to depict 
requirements in a way that is relatively easy to understand, and more important, 
straightforward to review for correctness, completeness, and consistency. 

Who does it? A software engineer (sometimes called an “analyst”) builds the model 
using 

requirements elicited from the customer. 

Why is it important? To validate software requirements, you need to examine them 
from a number of different points of view. In this chapter you'll consider 
requirements modeling from three different perspectives: scenario-based models, 
data (information) models, and class- based models. Each represents requirements 
in a different “dimension,” thereby increasing the probability that errors will be 
found, that inconsistency will surface, and that omissions willbe uncovered. 
Whatare the steps? Scenario-based modeling represents the system from the user’s 
point of view. Data modeling represents the information space and depicts the 
data objects thatthe software will manipulate and the relationships among them. 
Class-based modeling defines objects, attributes, and relationships. Once 
preliminary models are created, they are refined and analyzed to assess their clarity, 
completeness, and consistency. 


Whatis the work product? A wide array of text based and diagrammatic forms may 

be chosen for the requirements model. Each of these representations provides a view 

of one or more of the model elements. 

How do I ensure that I’ve done it right? Requirements modeling work products must 
bereviewed for correctness, completeness, and consistency. They must reflect the needs 
of all stakeholders and establish a foundation from which design can be conducted. 


2.0.1 REQUIREMENTS ANALYSIS 


Requirements analysis results in the specification of software’s operational 
characteristics, indicates software’s interface with other system elements, and 
establishes constraints that software must meet. Requirements analysis allows you to 
elaborate on basic requirements established during the inception, elicitation, and 
negotiation tasks that are part of requirements engineering. The requirements modeling 
action results in one or more of the following types of models: 

e Scenario-based models of requirements from the point of view of various system “actors” 
e Data models that depict the information domain for the problem 

e Class-oriented models that represent object-oriented classes (attributes and 
operations) andthe manner in which classes collaborate to achieve system requirements 
e Flow-oriented models that represent the functional elements of the system and 
how theytransform data as it moves through the system 
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e Behavioral models that depict how the software behaves as a consequence of 
external 
“events” 


These models provide a software designer with information that can be translated to 
architectural, interface, and component-level designs. Finally, the requirements model 
provides the developer and the customer with the means to assess quality once software 
is built. 


System 3 
description / 


Fig 6.1: The requirements model as a bridge 
between the system description and the desigr 
model 


Overall Objectives and Philosophy: Throughout requirements modeling, your primary 
focus is on what, not how. The requirements model must achieve three primary 
objectives: (1)to describe what the customer requires, (2) to establish a basis for the 
creation of a software design, and (3) to define a set of requirements that can be validated 
once the software is built. The analysis model bridges the gap between a system-level 
description that describes overall system or business functionality as it is achieved by 
applying software, hardware, data, human, and other system elements and a software 
design This relationship is illustrated in Figure 6.1 


Analysis Rules of Thumb: Arlow and Neustadt suggest a number of worthwhile rules of 
thumb that should be followed when creating the analysis model: 

° The model should focus on requirements that are visible within the problem or business 
domain. The level of abstraction should be relatively high. “Don’t get bogged down in 
details”that try to explain how the system will work. 


° Each element of the requirements model should add to an overall understanding of 
software requirements and provide insight into the information domain, function, and 
behavior of the system. 

e Delay consideration of infrastructure and other nonfunctional models until design. That 


is, a database may be required, but the classes necessary to implement it, the functions 
required to access it, and the behavior that will be exhibited as it is used should be 
considered only after problem domain analysis has been completed. 

e Minimize coupling throughout the system. It is important to represent relationships 
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between classes and functions. However, if the level of “interconnectedness” is extremely 

high, effort should be made to reduce it. 

e Be certain that the requirements model provides value to all stakeholders. Each 

constituency has its own use for the model. For example, business stakeholders should 

use the model to validate requirements; designers should use the model as a basis for 

design; QA people should use the model to help plan acceptance tests. 

e Keep the model as simple as it can be. Don’t create additional diagrams when they add no 
new 

information. Don’t use complex notational forms, when a simple list will do. 


Domain Analysis: The analysis patterns often reoccur across many applications within 
a specific business domain. If these patterns are defined and categorized in a manner 
that allows you to recognize and apply them to solve common problems. This improves 
time-to- market and reduces development costs. 


Technical literature 
Class taxonomies 
Existing applications 
Reuse standards Domai 
iomain 


Customer surveys Domain 


3 Functional models analysis 

Expert advice analysis BE 
Domain languages 

Current/future requirements 


Fig 6.2: Input and output for domain analysis 
Domain analysis doesn’t look at a specific application, but rather at the domain in 
which theapplication resides. The intent is to identify common problem solving 
elements that areapplicable to all applications within the domain. Domain analysis may 
be viewed as an umbrellaactivity for the software process. Figure 6.2 illustrates key 
inputs and outputs for the domainanalysis process. Sources of domain knowledge are 
surveyed in an attempt to identify objects that can be reused across the domain. 


Requirements Modeling Approaches: One view of requirements modeling, called 
structured analysis, considers data and the processes that transform the data as separate 
entities. Data objects are modeled in a way that defines their attributes and relationships. 
Processes that manipulate data objects are modeled in a manner that shows how they 
transformdata as data objects flow through the system. 

A second approach to analysis modeling, called object-oriented analysis, focuses on the 
definition of classes and the manner in which they collaborate with one another. UML 
and the Unified Process are predominantly object oriented. 

Each element of the requirements model (Figure 6.3) presents the problem from a 
different point of view. Scenario-based elements depict how the user interacts with the 
system and the specific sequence of activities that occur as the software is used. 
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Se nae Class-based elements model the objects that the 


S ee system will manipulate, the operations that will 

collaboration diogromsfbe applied to the objects to effect the 

manipulation, relationships between the objects, 

Tar and the collaborations that occur between the 

classes that are defined. Behavioral elements 

depict how external events change the state of 

re g. he system or the classes that reside within it. 
sequence diagrams Finally, flow- oriented elements represent the 
Fig 6.3: Elements of Analysis model system as an information transform, depicting 

how data objects are transformed as they flow through various system functions. 
Analysis modeling leads to the derivation of each of these modeling elements. However, 


the specific content of each element may differ from project to project. 


SCENARIO-BASED MODELING 


Requirements modeling with UML begins with the creation of scenarios in the form of use 
cases,activity diagrams, and swimlane diagrams. 


Creating a Preliminary Use Case: A use case describes a specific usage scenario in 
straightforward language from the point of view of a defined actor. But how do you know 
(1) whatto write about, (2) how much to write about it, (3) how detailed to make your 
description, and (4) how to organize the description? 


What to write about? The first two requirements engineering tasks—inception and 
elicitation— provide you with the information you'll need to begin writing use cases. 
Requirements gathering meetings, QFD, and other requirements engineering 
mechanisms are used to identify stakeholders, define the scope of the problem, specify 
overall operational goals, establish priorities, outline all known functional requirements, 
and describe the things (objects) that will be manipulated by the system. 

To begin developing a set of use cases, list the functions or activities performed by a 
specific actor. You can obtain these from a list of required system functions, through 
conversations with stakeholders, or by an evaluation of activity diagrams developed as 
part of requirements modeling. 


Refining a Preliminary Use Case: A description of alternative interactions is essential 

for a complete understanding of the function that is being described by a use case. 

Therefore, each step in the primary scenario is evaluated by asking the following 

questions. 

e Can the actor take some other action at this point? 

e Is it possible that the actor will encounter some error condition at this point? If so, what 

it be? 

— |) 
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e Is it possible that the actor will encounter some other behavior at this point. If so, what 

it be? Answers to these questions result in the creation of a set of secondary scenarios 
that are part ofthe original use case but represent alternative behavior. 

Can the actor take some other action at this point? The answer is “yes.” 

Is it possible that the actor will encounter some error condition at this point? Any number 
of errorconditions can occur as a computer-based system operates. 

Is it possible that the actor will encounter some other behavior at this point? Again the 
answer to the question is “yes.” 

In addition to the three generic questions suggested, the following issues should 

also beexplored: 

e Are there cases in which some “validation function” occurs during this use case? 

This implies that validation function is invoked and a potential error condition might occur. 
e Are there cases in which a supporting function (or actor) will fail to respond 
appropriately? Forexample, a user action awaits a response but the function that is to 
respond times out. 

e Can poor system performance result in unexpected or improper user actions? 


Writing a Formal Use Case: The informal use cases presented are sometimes sufficient 
for requirements modeling. However, when a use case involves a critical activity or 
describes a complex set of steps with a significant number of exceptions, a more formal 
approach may be desirable. 


[SafeHome 


Access camera 
-| Cameras 


Configure SafeHome 
\ system parameters 


Set alarm 


Fig 6.4: Preliminary use-case diagram for saftwHome system 
UML MODELS THAT SUPPLEMENT THE USE CASE 


A broad array of UML graphical models are as follows 

Developing an Activity Diagram: The UML activity diagram supplements the use case 
by providing a graphical representation of the flow of interaction within a specific 
scenario. Similar to the flowchart, an activity diagram uses rounded rectangles to imply 
a specific system function, arrows to represent flow through the system, decision 


diamonds to depict a branching decision and solid horizontal lines to indicate that 
ÁÁÁÁ- Á) 
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parallel activities are occurring. An activity diagram for the ACS-DCV use case is shown 
in Figure 6.5. 


Swimlane Diagrams: The UML swimlane diagram is a useful variation of the activity 
diagram and allows you to represent the flow of activities described by the use case and 
at the same time indicate which actor or analysis class has responsibility for the action 
described by anactivity rectangle. Responsibilities are represented as parallel segments 
that divide the diagram vertically, like the lanes in a swimming pool. Refer Figure 6.6. 
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Fig 6.5: Activity diagram for Access Camera surveillance via Internet display cams 
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Fig 6 6: Swimilane diagram for Access camera surveillance via the Internet—display camera 
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DATA MODELING CONCEPTS 


If software requirements include the need to create, extend, or interface with a database 
or if complex data structures must be constructed and manipulated, the software team 
may chooseto create a data model as part of overall requirements modeling. A software 
engineer or analyst defines all data objects that are processed within the system, the 
relationships between the data objects, and other information that is pertinent to the 
relationships. The entity-relationship diagram (ERD) addresses these issues and 
represents all data objects that are entered, stored, transformed, and produced within 
an application. 
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Data Objects: A data object is a representation of composite information that must be 
understood by software. Therefore, width (a single value) would not be a valid data 
object, but dimensions (incorporating height, width, and depth) could be defined as an 
object. 

A data object can be an external entity (e.g., anything that produces or consumes 
information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or 
event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting 
department), a place (e.g., a warehouse), or a structure (e.g., a file). The description of 
the data object incorporates the data object and all of its attributes. 


A data object encapsulates data only—there is no reference within a data object to 
operationsthat act on the data. 


Data Attributes: Data attributes define the properties of a data object and take on one 
ofthree different characteristics. They can be used to (1) name an instance of the data 
object, (2) describe the instance, or (3) make reference to another instance in another 
table. In addition,one or more of the attributes must be defined as an identifier—that is, 
the identifier attribute becomes a “key” when we want to find an instance of the data 
object. In some cases, values for the identifier(s) are unique, although this is not a 
requirement. 


Relationships: Data objects are connected to one another in different ways. Consider 
the two data objects, person and car. These objects can be represented using the simple 
notation illustrated in Figure 6.8a. A connection is established between person and car 
because the two objects are related. But what are the relationships? To determine the 
answer, you shouldunderstand the role of people (owners, in this case) and cars within 
the context of the softwareto be built. You can establish a set of object/relationship pairs 
that define the relevant relationships. For example, 

e A person owns a Car. 

e A person is insured to drive a car. 


ja) A basic connection between data 
objects 


owns 
Insured to car 
drive 
|b) Relationships between data 


i gb] ‘ a 
Fig 6.8: Relationships between data objects 
The relationships owns and insured to drive define the relevant connections between 
person andcar. Figure 6.8b illustrates these object-relationship pairs graphically. The 
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arrows noted in Figure 


6.8b provide important information about the directionality of the relationship and often 
reduceambiguity or misinterpretations. 


CLASS-BASED MODELING 


Class-based modeling represents the objects that the system will manipulate, the 
operations thatwill be applied to the objects to effect the manipulation, relationships 
between the objects, and the collaborations that occur between the classes that are 
defined. The elements of a class-based model include classes and objects, attributes, 
operations, class responsibility, collaborator(CRC) models, collaboration diagrams, and 
packages. 


Identifying Analysis Classes 
Classes are determined by underlining each noun or noun phrase and entering it into a 
simple table. If the class (noun) is required to implement a solution, then it is part of the 
solution space; otherwise, if a class is necessary only to describe a solution, it is part of 
the problem space. 
Analysis classes manifest themselves in one of the following ways: 
e External entities that produce or consume information to be used by a 


computer-basedsystem. 

e Things (e.g., reports, displays, letters, signals) that are part of the information domain 

for theproblem. 

e Occurrences or events (e.g., a property transfer or the completion of a series of robot 

movements) that occur within the context of system operation. 

e Roles (e.g., manager, engineer, salesperson) played by people who interact with the 
system. 

e Organizational units (e.g., division, group, team) that are relevant to an application. 

e Places (e.g., manufacturing floor or loading dock) that establish the context of the 

problem andthe overall function of the system. 

e Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of 

objects orrelated classes of objects. 


Specifying Attributes: Attributes are the set of data objects that fully define the class 
within the context of the problem. Attributes describe a class that has been selected for 
inclusionin the requirements model. In essence, it is the attributes that define the 
class—that clarify whatis meant by the class in the context of the problem space. 

To develop a meaningful set of attributes for an analysis class, you should study each use 
case 

and select those “things” that reasonably “belong” to the class. 
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Defining Operations: Operations define the behavior of an object. Although many 
different types of operations exist, they can generally be divided into four broad 
categories: (1) operations that manipulate data in some way. (2) operations that perform 
a computation, (3) operations that inquire about the state of an object, and (4) 
operations that monitor an object for the occurrence of a controlling event. These 
functions are accomplished by operating on attributes and/or associations. Therefore, 
an operation must have “knowledge” of the nature of the class’ attributes and 
associations. 

As a first iteration at deriving a set of operations for an analysis class, you can again study 
a processing narrative (or use case) and select those operations that reasonably belong 
to the class. To accomplish this, the grammatical parse is again studied and verbs are 
isolated. Some of these verbs will be legitimate operations and can be easily connected 
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Fig 6.9: Class diagram for the System class. 
to a specific class. 
Class-Responsibility-Collaborator (CRC) Modeling: Class-responsibility-collaborator 
(CRC) modeling provides a simple means for identifying and organizing the classes that 
are relevant to system or product requirements. 


One purpose of CRC cards is to fail early, to fail often, and to fail inexpensively. It is a lot 
cheaper to tear up a bunch of cards than it would be to reorganize a large amount of 
source code. 


Ambler describes CRC modeling in the following way: 

A CRC model is really a collection of standard index cards that represent classes. The 
cards are divided into three sections. Along the top of the card you write the name of the 
class. In the body of the card you list the class responsibilities on the left and the 
collaborators on the right. 
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In reality, the CRC model may make use of actual or virtual index cards. The intent is to 
developan organized representation of classes. Responsibilities are the attributes and 
operations that are relevant for the class. Stated simply, a responsibility is “anything the 
class knows or does”. Collaborators are those classes that are required to provide a class 
with the information needed to complete a responsibility. 

In general, a collaboration implies either a request for information or a request for some 
action. 


A simple CRC index card for the FloorPlan class is illustrated in Figure 6.11. The list of 
responsibilities shown on the CRC card is preliminary and subject to additions or 
modification. The classes Wall and Camera are noted next to the responsibility that will 
require their collaboration. 

Classes. Basic guidelines for identifying classes and objects were presented earlier in 


Fig 6.10: Class diagram 
for FloorPlan 


determine! 
peti tL 2 
soo 


change color{ } 


ls placed within » 


YED 


wi imensions 


location 


fieldView 
pra le 
oom determinelypet } 


determinelypel } computeDimensions ( } 
slatelocation| | 
D{) 
h 


i « |s used to build 
Is used to build 


ordnas 


stopCoordinates s stopCoordinates 
nextWallSement next Window nextDoor 


determine h determinelypel determine! 
2 ac | om ake i 


DEPT. OF ISE 


21CS61- Software Engineering and Project Management 


this chapter. The taxonomy of class types presented in Section 6.5.1 can be extended by 
considering the following categories: 

e Entity classes, also called model or business classes, are extracted directly from the 
statement of the problem These classes typically represent things that are to be stored 
in a database and persist throughout the duration of the application. 

e Boundary classes are used to create the interface (e.g., interactive screen or printed 
reports)that the user sees and interacts with as the software is used. Entity objects 
contain information 


that is important to users, but they do not display themselves. Boundary classes are 
designedwith the responsibility of managing the way entity objects are represented to 


ee ie O 
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Fig 6.11: A CRC model index card 

users. 

e Controller classes manage a “unit of work” from start to finish. That is, controller classes 
can be designed to manage (1) the creation or update of entity objects, (2) the 
instantiation of boundary objects as they obtain information from entity objects, (3) 
complex communication between sets of objects, (4) validation of data communicated 
between objects or between the user and the application. In general, controller classes 
are not considered until the design activity has begun. 


Responsibilities. The five guidelines for allocating responsibilities to classes: 

1. System intelligence should be distributed across classes to best address the 

needs ofthe problem. Every application encompasses a certain degree of intelligence; 

that is, what the system knows and what it can do. This intelligence can be distributed 

acrosss classes in a umber of different ways. “Dumb” classes can be modeled to act as 

servants to a few “smart” classes. 

To determine whether system intelligence is properly distributed, the responsibilities 

noted on each CRC model index card should be evaluated to determine if any class has 
E) 
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an extraordinarilylong list of responsibilities. Example is aggregation of classes. 

2. Each responsibility should be stated as generally as possible. This guideline 
implies thatgeneral responsibilities (both attributes and operations) should reside high 
in the class hierarchy 
3. Information and the behavior related to it should reside within the same class. 
This achieves the object-oriented principle called encapsulation. Data and the processes 
that manipulate the data should be packaged as a cohesive unit. 
4. Information about one thing should be localized with a single class, not 
distributed across multiple classes. A single class should take on the responsibility for 
storing and manipulating a specific type of information. This responsibility should not, 
in general, be shared 


across a number of classes. If information is distributed, software becomes more difficult 
to maintain and more challenging to test. 

5. Responsibilities should be shared among related classes, when appropriate. 
There are many cases in which a variety of related objects must all exhibit the same 
behavior at the same time. 


Collaborations. Classes fulfill their responsibilities in one of two ways: (1) A class can 
use its own operations to manipulate its own attributes, thereby fulfilling a particular 
responsibility, or (2)a class can collaborate with other classes. 

To help in the identification of collaborators, you can examine three different generic 
relationships between classes (1) the is-part-of relationship, (2) the has-knowledge-of 
relationship, and (3) the depends-upon relationship. 


Fig 6.12: A composite 
aggregate 
class 


When a complete CRC model has been developed, stakeholders can review the model 
usingthe following approach 

1. All participants in the review are given a subset of the CRC model index cards. 
Cards thatcollaborate should be separated 
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2. All use-case scenarios (corresponding use-case diagrams) should be organized 
intocategories. 

3. The review leader reads the use case deliberately. 

4. When the token is passed, the holder of the Sensor card is asked to describe the 
responsibilities noted on the card. 

5. If the responsibilities and collaborations noted on the index cards cannot 
accommodate theuse case, modifications are made to the cards. 


This continues until the use case is finished. When all use cases have been reviewed, 
requirements modeling continue. 


Associations and Dependencies: In many instances, two analysis classes are related to 
one another in some fashion, much like two data objects may be related to one another. 
In UML these relationships are called associations. 

In some cases, an association may be further defined by indicating multiplicity. 
Referring to The multiplicity constraints are illustrated in Figure 6.13, where “one 

or more” is represented 

using 1. .*, and “O or more” by 0. .*. In UML, the asterisk indicates an unlimited upper 
bound onthe range. 


Fig 6.13 Multiplicity 
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Fig 6.14: Dependencies 
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Analysis Packages: An important part of analysis modeling is categorization. That is, 
various elements of the analysis model are categorized in a manner that packages 
them as a grouping—called an analysis package—that is given a representative name. 

For example, Classes such as Tree, Landscape, Road, Wall, Bridge, Building, and 
VisualEffectmight fall within this category. Others focus on the characters within the game, 
describing their physical features, actions, and constraints. 

These classes can be grouped in analysis packages as shown in Figure 6.15. The plus 
signpreceding the analysis class name in each package indicates that the classes have 
public visibility and are therefore accessible from other packages. 
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Although they are not shown in the figure, other symbols can precede an element 
within a package. A minus sign indicates that an element is hidden from all other 
packages and a #symbol indicates that an element is accessible only to packages 
contained within a given package. 
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Fig 6.15: Packages 
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Module - III 


AGILE DEVELOPMENT: What is Agility?, Agility and the cost of change. What is an agile Process?, 
Extreme Programming (XP), Other Agile Process Models, A tool set for Agile process 

Principles that guide practice: Software Engineering Knowledge, Core principles, Principles that 
guide each framework activity 

Textbook 1: Chater 3: 3.1 to 3.6, Chapter 4: 4.1 to 4.4 


WHAT IS AGILITY? 


An agile team is a nimble team able to appropriately respond to changes. Change is what 
software development is very much about. Changes in the software being built, changes to the 
team members, changes because of new technology, changes of all kinds that may have an 
impact on the product they build or the project that creates the product. Support for changes 
should be built-in everything we do in software, something we embrace because it is the heart 
and soul of software. An agile team recognizes that software is developed by individuals working 
in teams and that the skills of thesepeople, their ability to collaborate is at the core for the 
success of the project. 


It encourages team structures and attitudes that make communication (among team members, 
between technologists and business people, between software engineersand their managers) 
more facile. It emphasizes rapid delivery of operational software and de-emphasizes the 
importance of intermediate work products. 


Agility can be applied to any software process. However, to accomplish this, it is essential that 


the process be designed in a way that allows the project team to adapt tasks and to streamline 
them, conduct planning in a way that understands the fluidity of an agile development approach, 
eliminate all but the most essential work products and keep them lean, and emphasize an 
incremental delivery strategy that gets working software to the customer as rapidly as feasible 
for the product type and operational environment. 


AGILITY AND THE COST OF CHANGE 

The conventional wisdom in software development is that the cost of change increases 
nonlinearly as a project progresses (Figure: solid black curve). It is relatively easy to 
accommodate a change when a software team is gathering requirements (early in a project). 
A usage scenario might have to be modified, a list of functions may be extended, or a written 
specification can be edited. The costs of doing this work are minimal, and the time required will 
not adversely affect the outcome of the project. 


The change requires a modification to the architectural design of the software, the design and 
construction of three new components, modifications to another five components, the design of 
new tests, and so on. Costs escalate quickly, and the time and cost required to ensure that the 
change is made without unintended side effects is nontrivial. Although debate about the degree 
to which the cost curve flattens is ongoing, there is evidence to suggest that a significant 
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reduction in the cost of change can be achieved. 


Cost of change 
using conventional 
software processes 


Cost of change 
using agile processes 


Pa idealized cost of change 
k using agile process 


i Development schedule progress 
Fig 2.11: Change Costs as a function of time in development 


Development cost 


WHAT IS AN AGILE PROCESS? 

Any agile software process is characterized in a manner that addresses a number of key 
assumptions about the majority of software projects: 

1. It is difficult to predict in advance which software requirements will persist and which will 
change. It is equally difficult to predict how customer priorities will change as the project 
proceeds. 

2. For many types of software, design and construction are interleaved. That is, both activities 
should be performed in tandem so that design models are proven as they are created. It is 
difficult to predict how much design is necessary before construction is used to prove the design. 


3. Analysis, design, construction, and testing are not as predictable as we might like. Given these 
three assumptions, an important question arises: How do we create aprocess that can 
manage unpredictability? The answer, as I have already noted, lies inprocess adaptability. An 
agile process, therefore, must be adaptable. But continualadaptation without forward 
progress accomplishes little. Therefore, an agile software process must adapt incrementally. 
To accomplish incremental adaptation, an agile teamrequires customer feedback. An effective 
catalyst for customer feedback is an operational prototype or a portion of an operational system. 
Hence, an incremental development strategy should be instituted. Software increments must be 
delivered in short time periods so that adaptation keeps pace with change. This iterative 
approach enables the customer to evaluate the software increment regularly, provide necessary 
feedback to the software team, and influence the process adaptations that are made to 
accommodate the feedback. 


Agility Principles: The Agile Alliance defines 12 agility principles for those whowant to 
achieve agility: 


Y Our highest priority is to satisfy the customer through early and continuous delivery of 
valuable software. 
y Welcome changing requirements, even late in development. Agile processes harness 
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change for the customer’s competitive advantage. 

Deliver working software frequently, from a couple of weeks to a couple of months,with 
a preference to the shorter timescale. 

Business people and developers must work together daily throughout the project. 

Build projects around motivated individuals. Give them the environment and supportthey 
need, and trust them to get the job done. 

The most efficient and effective method of conveying information to and within a 
development team is face-to-face conversation. 

Working software is the primary measure of progress. 

Agile processes promote sustainable development. The sponsors, developers, andusers 
should be able to maintain a constant pace indefinitely. 

Continuous attention to technical excellence and good design enhances agility. 
Simplicity—the art of maximizing the amount of work not done—is essential. 

The best architectures, requirements, and designs emerge from self-organizingteams. 

At regular intervals, the team reflects on how to become more effective, then tunesand 
adjusts its behavior accordingly. 


The Politics of Agile Development: There is considerable debate about the benefits and 
applicability of agile software development as opposed to more conventional software 
engineering processes. No one is against agility. The real question is: What is the best way to 
achieve it? As important, how do you build software that meets customers’ needs today and 
exhibits the quality characteristics that will enable it to be extended and scaled to meet 
customers’ needs over the long term? 


There are no absolute answers to either of these questions. Even within the agile schoolitself, 
there are many proposed process models, each with a subtly different approachto the agility 
problem. Within each model there is a set of “ideas” that represent a significant departure 
from traditional software engineering. And yet, many agile concepts are simply adaptations of 
good software engineering concepts. Bottom line: there is much that can be gained by 
considering the best of both schools and virtually nothing to be gained by denigrating either 
approach. 


Human Factors: Proponents of agile software development take great pains to emphasize the 
importance of “people factors.” If members of the software team are to drive the characteristics 
of the process that is applied to build software, a number of key traits must exist among the 
people on an agile team and the team itself: 

Competence: In an agile development (as well as software engineering) context, “competence” 
encompasses innate talent, specific software-related skills, and overall knowledge of the process 


that the team has chosen to apply. Skill and knowledge of process can and should be taught to 
all people who serve as agile team members. 
Common focus:. Although members of the agile team may perform different tasks and bring 


different skills to the project, all should be focused on one goal—to deliver a working software 
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increment to the customer within the time promised. To achieve this goal, the team will also 
focus on continual adaptations (small and large) that will make the process fit the needs of the 
team. 

Collaboration: Software engineerinG is about assessing, analyzing, and using information that 
is communicated to the software team; creating information that will help all stakeholders 
understand the work of the team; and building information that provides business value for the 
customer. To accomplish these tasks, team members must collaborate—with one another and 
all other stakeholders. 

Decision-making ability. Any good software team must be allowed the freedom to control its 
own destiny. This implies that the team is given autonomy—decision-making authority for both 
technical and project issues. 

Fuzzy problem-solving ability. Software managers must recognize that the agile team will 
continually have to deal with ambiguity and will continually be buffeted by change. Insome 
cases, the team must accept the fact that the problem they are solving today may not be the 
problem that needs to be solved tomorrow. However, lessons learned from any problem-solving. 
activity (including those that solve the wrong problem) may be of benefit to the team later in 
the project. 

Mutual trust and respect. The agile team must become what DeMarco and Lister calla “jelled” 
team. A jelled team exhibits the trust and respect that are necessary to make them “so strongly 
knit that the whole is greater than the sum of the parts.” 

Self-organization. In the context of agile development, self-organization implies three things: 
(1) the agile team organizes itself for the work to be done, (2) the team organizes the process 
to best accommodate its local environment, (3) the team organizes the work schedule to best 
achieve delivery of the software increment. Self- organization has a number of technical benefits, 


but more importantly, it serves to improve collaboration and boost team morale. In essence, the 
team serves as its own management. 


EXTREME PROGRAMMING (XP) 


Extreme Programming (XP), the most widely used approach to agile software 
development. 
XP Values: Beck defines a set of five values that establish a foundation for all work performed 
as part of XP—communication, simplicity, feedback, courage, and respect. Each of these 
values is used as a driver for specific XP activities, actions, andtasks. 
Communication: In order to achieve effective communication between software engineers and 
other stakeholders (e.g., to establish required features and functions for the software), XP 
emphasizes close, yet informal (verbal) collaboration between customers and developers, the 
establishment of effective metaphors for communicating important concepts, continuous 
feedback, and the avoidance of voluminous documentation as a communication medium. 
Simplicity: To achieve simplicity, XP restricts developers to design only for immediate needs, 
rather than consider future needs. The intent is to create a simple design thatcan be easily 
implemented in code. If the design must be improved, it can be refactored at a later time. 
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Feedback: It is derived from three sources: the implemented software itself, the customer, and 
other software team members. By designing and implementing an effective testing strategy, the 
software provides the agile team with feedback The degree to which the software implements 
the output, function, and behavior of the use case is a form of feedback. Finally, as new 
requirements are derived as part of iterative planning, the team provides the customer with 
rapid feedback regarding cost and schedule impact. 

Courage: Beck argues that strict adherence to certain XP practices demands courage.A better 
word might be discipline. An agile XP team must have the discipline (courage) to design for 
today, recognizing that future requirements may change dramatically, thereby demanding 
substantial rework of the design and implemented code. 

Respect: By following each of these values, the agile team inculcates respect amongits 
members, between other stakeholders and team members, and indirectly, for the software 
itself. As they achieve successful delivery of software increments, the team develops growing 
respect for the XP process. 


The XP Process: Extreme Programming uses an object-oriented approach as itspreferred 
development paradigm and encompasses a set of rules and practices that occur within the 
context of four framework activities: planning, design, coding, and testing. Figure 3.2 illustrates 
the XP process . 


Planning: The planning activity begins with listening—a requirements gathering activity 
that enables the technical members of the XP team to understand the business context for the 
software and to get a broad feel for required output and major features and functionality. 


Design: XP design rigorously follows the KIS (keep it simple) principle. A simple design is 
always preferred over a more complex representation. In addition, the design provides 
implementation guidance for a story as it is written—nothing less, nothingmore. If a difficult 
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Fig 2.12: Adaptive software development postmortems 
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design problem is encountered as part of the design of a story, XP recommends the immediate 
creation of an operational prototype of that portion of the design. Called a spike solution, the 
design prototype is implemented and evaluated. A central notion in XP is that design occurs both 
before and after coding commences. Refactoring means that design occurs continuously as the 
system is constructed. In fact, the construction activity itself will provide the XP team with 
guidance on how to improve the design. 

Coding. After stories are developed and preliminary design work is done, the teamdoes not 
move to code, but rather develops a series of unit tests that will exercise each of the stories that 
is to be included in the current release. Once the unit test has been created, the developer is 
better able to focus on what must be implemented to pass the test. Nothing extraneous is added 
(KIS). Once the code is complete, it can be unit-tested immediately, thereby providing 
instantaneous feedback to the developers. 

A key concept during the coding activity is pair programming. XP recommends that two people 
work together at one computer workstation to create code for a story. Problem solving (two 
heads are often better than one) and real-time quality assurance. 

Testing: | have already noted that the creation of unit tests before coding commences 

is a key element of the XP approach. The unit tests that are created should be implemented using 
a framework that enables them to be automated. This encourages a regression testing strategy 
whenever code is modified. As the individual unit tests are organized into a “universal testing 
suite”. 

integration and validation testing of the system can occur on a daily basis. XP acceptance tests, 
also called customer tests, are specified by the customer and focus on overall system features 
and functionality that are visible and reviewable by the customer. 


Industrial XP: IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer- 
centric, test-driven spirit. IXP incorporates six new practices that are designed to help ensure 


that an XP project works successfully for significant projects within a large organization. 
Readiness assessment: Prior to the initiation of an IXP project, the organization shouldconduct 


a readiness assessment. The assessment ascertains whether (1) an appropriate development 
environment exists to support IXP, (2) the team will be populated by the proper set of 
stakeholders, (3) the organization has a distinct quality program and supports continuous 
improvement, (4) the organizational culture will support the new values of an agile team, and 
(5) the broader project community will be populated appropriately. 

Project community. Classic XP suggests that the right people be used to populate the agile team 
to ensure success. The implication is that people on the team must be well- trained, adaptable 
and skilled, and have the proper temperament to contribute to a self- organizing team. When XP 
is to be applied for a significant project in a large organization, the concept of the “team” should 
morph into that of a community. Acommunity may have a technologist and customers who are 
central to the success of a project as well as many other stakeholders (e.g., legal staff, quality 
auditors, manufacturing or sales types) who “are often at the periphery of an IXP project yet 
they may play important roles on the project”. In IXP, the community members and their roles 
should be explicitly defined and mechanisms for communication and coordination between 
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community members should be established. 

Project chartering. The IXP team assesses the project itself to determine whether an 
appropriate business justification for the project exists and whether the project will further the 
overall goals and objectives of the organization. Chartering also examines the context of the 
project to determine how it complements, extends, or replaces existing systems or processes. 
Test-driven management. An IXP project requires measurable criteria for assessing the state 
of the project and the progress that has been made to date. Test-driven management establishes 
a series of measurable “destinations” and then defines mechanisms for determining whether or 
not these destinations have been reached. 

Retrospectives. An IXP team conducts a specialized technical review after a software increment 
is delivered. Called a retrospective, the review examines “issues, events, and lessons-learned” 
across a software increment and/or the entire software release. The intent is to improve the 
IXP process. Continuous learning. Because learning is a vitalpart of continuous process 
improvement, members of the XP team are encouraged to learn new methods and techniques 
that can lead to a higher quality product. 


The XP Debate: Issues that continue to trouble some critics of XP are: 

O Requirements volatility. Because the customer is an active member of the XP team, 
changes to requirements are requested informally. As a consequence, the scope of the project 
can change and earlier work may have to be modified to accommodate current needs. 

: Conflicting customer needs. Many projects have multiple customers, each with his own 
set of needs. In XP, the team itself is tasked with assimilating the needs of different customers, a 
job that may be beyond their scope of authority. 

° Requirements are expressed informally. User stories and acceptance tests are the only 
explicit manifestation of requirements in XP. Critics argue that a more formal model or 
specification is often needed to ensure that omissions, inconsistencies, and errorsare 
uncovered before the system is built. Proponents counter that the changing nature of 
requirements makes such models and specification obsolete almost as soon as they are 
developed. 

° Lack of formal design. XP deemphasizes the need for architectural design and in many 
instances, suggests that design of all kinds should be relatively informal. 


OTHER AGILE PROCESS MODELS 


The most widely used of all agile process models is Extreme Programming (XP). But many other 
agile process models have been proposed and are in use across theindustry. Among the most 
common are: 

e Adaptive Software Development (ASD) 

e Scrum 


* Dynamic Systems Development Method (DSDM) 
e Crystal 
e Feature Drive Development (FDD) 
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e Lean Software Development (LSD) 
e Agile Modeling (AM) 
e Agile Unified Process (AUP) 


Adaptive Software Development (ASD): Adaptive Software Development (ASD) has been 
proposed by Jim Highsmith as a technique for building complex software and systems. The 
philosophical underpinnings of ASD focus on human collaboration and team self-organization. 
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Fig 2.13: Adaptive software development postmortems 


Scrum: Scrum is an agile software development method that was conceived by Jeff Sutherland 
in the early 1990s. Scrum principles are consistent with the agile manifesto and are used to guide 
development activities within a process that incorporates the following framework activities: 
requirements, analysis, design, evolution, and delivery. Within each framework activity, work 
tasks occur within a process pattern called a sprint. The work conducted within a sprint is 
adapted to the problem at hand and is defined and often modified in real time by the Scrum team. 
The overall flow of the Scrum process is illustrated in Figure 
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Scrum: 15 minute daily meeting 
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Fig 2.14: Scrum Process flow 


Scrum emphasizes the use of a set of software process patterns that have proven effective for 
projects with tight timelines, changing requirements, and business criticality.Each of these 
process patterns defines a set of development actions: 

Backlog—a prioritized list of project requirements or features that provide business value for 
the customer. Items can be added to the backlog at any time. The product manager assesses the 
backlog and updates priorities as required. 

Sprints—consist of work units that are required to achieve a requirement defined in the backlog 
that must be fit into a predefined time-box. 

Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint allows 
team members to work in a short-term, but stable environment. 


Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum team. 
Three key questions are asked and answered by all team members: 

What did you do since the last team meeting? 

What obstacles are you encountering? 

What do you plan to accomplish by the next team meeting? 

A team leader, called a Scrum master, leads the meeting and assesses the responses from each 


person. The Scrum meeting helps the team to uncover potential problems as early as possible. 
Also, these daily meetings lead to “knowledge socialization” and thereby promote a self- 
organizing team structure. 

Demos—deliver the software increment to the customer so that functionality that has been 
implemented can be demonstrated and evaluated by the customer. It is important to note that 
the demo may not contain all planned functionality, but rather those functions that can be 
delivered within the time-box that was established. 


Dynamic Systems Development Method (DSDM): The Dynamic Systems Development 
Method (DSDM) is an agile software development approach that “provides a framework for 
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building and maintaining systems which meet tight time constraints through the use of 
incremental prototyping in a controlled project environment”. The DSDM philosophy is 
borrowed from a modified version of the Pareto principle—80 percent of an application can be 
delivered in 20 percent of the time it would take to deliver the complete (100 percent) 
application. 


DSDM is an iterative software process in which each iteration follows the 80 percentrule. 
That is, only enough work is required for each increment to facilitate movement to the next 
increment. The remaining detail can be completed later when more business requirements are 
known or changes have been requested and accommodated. 

DSDM consortium has defined an agile process model, called the DSDM life cycle thatdefines 
three different iterative cycles, preceded by two additional life cycle activities: 

Feasibility study—establishes the basic business requirements and constraints associated 
with the application to be built and then assesses whether the application isa viable 
candidate for the DSDM process. 

Business study—establishes the functional and information requirements that will allow the 
application to provide business value; also, defines the basic application architecture and 
identifies the maintainability requirements for the application. 

Functional model iteration—produces a set of incremental prototypes that demonstrate 
functionality for the customer. The intent during this iterative cycle is to gather additional 
requirements by eliciting feedback from users as they exercise the prototype. 


Design and build iteration—revisits prototypes built during functional model iteration to 


ensure that each has been engineered in a manner that will enable it to provide operational 
business value for end users. In some cases, functional model iteration and design and build 
iteration occur concurrently. 

Implementation—places the latest software increment into the operational environment. It 
should be noted that (1) the increment may not be 100 percent completeor (2) changes may be 
requested as the increment is put into place. In either case, DSDM development work continues 
by returning to the functional model iteration activity. 


Crystal: To achieve maneuverability, Cockburn and Highsmith have defined a set of 
methodologies, each with core elements that are common to all, and roles,process patterns, 
work products, and practice that are unique to each. The Crystalfamily is actually a set of 
example agile processes that have been proven effective for different types of projects. The intent 
is to allow agile teams to select the member of the crystal family that is most appropriate for 
project and environment. 


Feature Driven Development (FDD): Like other agile approaches, FDD adoptsa philosophy 
that (1) emphasizes collaboration among people on an FDD team; (2) manages problem and 
project complexity using feature-based decomposition followed by the integration of software 
increments, and (3) communication of technical detail using verbal, graphical, and text-based 
means. FDD emphasizes software quality assurance activities by encouraging an incremental 
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development strategy, the use of design and code inspections, the application of software quality 
assurance audits, the collection of metrics, and the use of patterns 


In the context of FDD, a feature “is a client-valued function that can be implemented in two 
weeks or less”. The emphasis on the definition of features provides the following benefits: 
Because features are small blocks of deliverable functionality, users can describethem more 
easily; understand how they relate to one another more readily; and better review them for 
ambiguity, error, or omissions. 

Features can be organized into a hierarchical business-related grouping. 

Since a feature is the FDD deliverable software increment, the team develops 


operational features every two weeks. Because features are small, their design 
and code representations are easier toinspect effectively. 
Project planning, scheduling, and tracking are driven by the feature hierarchy,rather than 


an arbitrarily adopted software engineering task set. 
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Fig 2.14: Feature Driven Development 


Lean Software Development (LSD): The lean principles that inspire the LSD process can be 
summarized as eliminate waste, build quality in, create knowledge, defer commitment, deliver 
fast, respect people, and optimize the whole. Each of these principles can be adapted to the 
software process. For example, eliminate waste within the context of an agile software project 
can be interpreted to mean (1) adding no extraneous features or functions, (2) assessing the cost 
and schedule impact of any newly requested requirement, (3) removing any superfluous process 
steps, (4) establishing mechanisms to improve the way team members find information, (5) 
ensuring the testing finds as many errors as possible, (6) reducing the time required to request 
and get a decision that affects the software or the process that is applied to create it, and (7) 
streamlining the manner in which information is transmitted to all stakeholders involved in the 
process. 


Agile Modeling (AM): There are many situations in which software engineers must build large, 
business critical systems. The scope and complexity of such systems must be modeled so that 
(1) all constituencies can better understand what needs to be accomplished, (2) the problem can 
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be partitioned effectively among the people whomust solve it, and (3) quality can be assessed 
as the system is being engineered and built. 


Agile modeling adopts all of the values that are consistent with the agile manifesto. The agile 
modeling philosophy recognizes that an agile team must have the courage to make decisions 
that may cause it to reject a design and re factor. The team must also have the humility to 
recognize that technologists do not have all the answers and that business expert and other 
stakeholders should be respected and embraced. Although AM suggests a wide array of “core” 
and “supplementary” modeling principles, those that make AM unique are: 

Model with a purpose 

Use multiple models 

Travel light 

Content is more important than representation 

Know the models and the tools you use to create them 

Adapt locally 


Agile Unified Process (AUP): The Agile Unified Process (AUP) adopts a “serial in the large” and 
“iterative in the small” philosophy for building computer-based systems.By adopting the classic 
UP phased activities—inception, elaboration, construction, and transition—AUP provides a 
serial overlay that enables a team to visualize the overall process flow for a software project. 
However, within each of the activities, the team iterates to achieve agility and to deliver 
meaningful software increments to end users as rapidly as possible. Each AUP iteration 
addresses the following activities 

e Modeling. UML representations of the business and problem domains are created. However, 
to stay agile, these models should be “just barely good enough’ to allow the team to proceed. 

e Implementation. Models are translated into source code. 

e Testing. Like XP the team designs and executes a series of tests to uncover errors and ensure 
that the source code meets its requirements. 

e Deployment. Like the generic process activity. Deployment in this context focuses on the 
delivery of a software increment and the acquisition of feedback from end users. 

e Configuration and project management. In the context of AUP, configuration management 
addresses change management, risk management, and the control of any persistent work 


products that are produced by the team. Project management tracks and controls the progress 


of the team and coordinates team activities. 


e Environment management. Environment management coordinates a process 
infrastructure that includes standards, tools, and other support technology available to the team. 
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Module-IV 


Introduction to software project management 
Project Management is the discipline of defining and achieving targets while optimizing the use 
of resources (time, money, people, materials, energy, space, etc) over the course of a project (a set 
of activities of finite duration). 
Why is Software project management important? 

e Large amounts of money are spent on ICT(/nformation and communications technology) 
e.g. UK government in 2003-4 spent £2.3 billions on contracts for ICT and only £1.4 billions on 
road building 

e Project often fail - Standish Group claim only a third of ICT projects are successful. 82% 

were late and 43% exceeded their budget. 

e Poor project management a major factor in these failures 

e 1 billion = 100 crore 
Software Development Life Cycle: 
The software development life-cycle is a methodology that also forms the framework for planning 
and controlling the creation, testing, and delivery of an information system. 
The software development life-cycle concept acts as the foundation for multiple different 
development and delivery methodologies, such as the Hardware development life- cycle and 
Software development life-cycle. While Hardware development life-cycles deal specifically with 
hardware and Software development life-cycles deal specifically with software, a Systems 
development life-cycle differs from each in that it can deal with any combination of hardware and 
software, as a system can be composed of hardware only, software only, or a combination of both. 


Four Project Dimensions 
o People 
o Process 
o Product 
o Technology 
The 5 Variables of Project Control 
1. Time - amount of time required to complete the project. 
2. Cost - calculated from the time variable 
3. Quality - The amount of time put into individual tasks determines the 
overall quality of the project. 
4. Scope - Requirements specified for the end result. 
5. Risk - Potential points of failure. 
Trade - off triangle: 
The triangle illustrates the relationship between three primary 
forces in a project. Time is the available time to deliver the project, 
V. cost represents the amount of money or resources available and 
quality represents the fit-to-purpose that the project must achieve 
to be a success. 
The normal situation is that one of these factors is fixed and the 
other two will vary in inverse proportion to each other. For example 
time is often fixed and the quality of the end product will depend on the cost or resources 
available. Similarly if you are working to a fixed level of quality then the cost of the project will 
largely be dependent upon the time available (if you have longer you can do it with fewer people). 
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Project definition 


What is a project? 
Some dictionary definitions: 
“A specific plan or design” 
“A planned undertaking” 
“A large undertaking e.g. a public works scheme” 
Longmans dictionary Key points above are planning and size of task 
Jobs versus projects 


Uncertainty 
of outcome 


_Jobs‘ - repetition of very well-defined and well understood tasks with very little uncertainty 
_Exploration‘ - e.g. finding a cure for cancer: the outcome is very uncertain 
Projects - in the middle! 
e Jobs- Very Little Uncertainty 
e Task is well defined and there is little uncertainty. 
e Software Process Management vs Software Project Management 
Projects 
e Projects seem to come somewhere between these two extremes. There are usually well- 
defined hoped-for outcomes but there are risks and uncertainties about achieving those 
outcomes. 
A software project can be defined as a planned activity that describes how we are going 
to carry out a task before we start. 
It is a planned activity about developing a software before u actually design and 
implement it. 
Examples of Software Projects: 
Putting a robot vehicle on Mars to search for signs of life. 
Relative novelty of the project 
International nature of the project 
Successful achievement of the project from engineering point of view is the safe landing of the robot, 
not the discovery of signs of life. 
Writing an Operating System 


Characteristics of projects 
A task is more _project-like' if it is: 
e Non-routine tasks are involved 
e Planning is required 
e Aiming ata specific target 
e Carried out for a customer 
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Carried out by a temporary work group 
Involving several specialisms 
Made up of several different phases 

e Constrained by time and resources 

e Large and/or complex 

Are software projects really different from other projects? Not really ...but 

e Invisibility: Software project management can be seen as the process of making invisible 
to visible 
Complexity: software products contain more complexity than other engineered artefacts. 
Conformity: Software developers have to conform to the requirements of human clients. 
Flexibility: Easy to change is strength, but 


Contract management and Technical Project management 
Projects can be: 
e In-house: clients and developers are employed by the same organization 
e Out-sourced: clients and developers employed by different organizations 
e _Project manager‘ could be: 
— a_contract manager’ in the client organization 
— atechnical project manager in the supplier/services organization 
e Representing - liaising with clients, users, developers and other stakeholders 
Activities covered by project management 
A software project is not only concerned with the actual writing of software. Usually there are three 
successive processes that bring a new system into being. 
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Project execution 


Feasibility study 

Is project technically feasible and worthwhile from a business point of view?(recommendation of 
the feasibility study might be not to carry out the proposed project) 

Planning 

Only done if project is feasible - evolving plan allows us to control the project. 

Execution 

Implement plan, but plan may be changed as we go along 


The software development life-cycle (ISO 12207) 
The software development life cycle is a technical model. It identifies the technical constraints on 
the order activities are done. This does NOT imply that a _waterfall‘ approach is the only way to 
organize projects. The technical model could be implemented as increments or in an evolutionary 
manner. 
ISO 12207 life-cycles are: 

1. Requirements analysis 

2. Architecture Design 
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3. Code and test 
4. Installation \ Acceptance support 


Requirements analysis 
Architecture design 
Requirements analysis 
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Acceptance support 
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Requirements analysis 
— Requirements eli-ci-tation(kindle): what does the client need? 
— Analysis: converting _customer-facing’ requirements into equivalents that 
developers can understand 
— Requirements will cover 
e Functions 
e Quality 
e Resource constraints i.e. costs 
Requirement analysis has to face in (at least) two different directions. It needs to communicate and 
elicit the requirements of the users, speaking in their language. It needs to organize and translate 
those requirements into a form that developers can understand and relate to. 
Architecture Design 


— Based on system requirements 
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— Defines components of system: hardware, software, organizational 
— Software requirements will come out of this 
Code and test 
— Of individual components (separately coded and tested) 
e Integration 
- Putting the components together 
e Qualification testing(the whole system) 
- Testing the system (not just the software) 
e Installation(meaning most like implementation) Install -Complete System 
— The process of making the system operational 
— Includes setting up standing data, setting system parameters, installing on 
operational hardware platforms, user training etc 
e Acceptance support 
- Including maintenance and enhancement 


Plans, methods and methodologies 
e Aplan of an activity must be based on some idea of a method of work. While a method 
relates to a type of activity in general, a plan takes one or more methods and converts 
them into real activities by identifying: 
Start and end dates 
Who will carry it out 
What tools and materials would be needed. 
e Amethodology is a set of related methods. Strictly speaking methodology“ ought to mean 
the study of methods! 
Plans, methods and methodologies Methodology = a set of methods 


Context 


+ start and end dates for each activity, 4 way of working staffing, tools and materials etc 


Some ways of categorizing projects 
Distinguishing different types of project is important as different types of task need different project 
approaches e.g. 
e Voluntary systems (such as computer games -what game will do?) versus compulsory 
systems e.g. the order processing system in an organization(recording a sale) 
e Information systems(Enable staff to carry out office processes) versus 
embedded systems(process control-which controls machine) 
e Objective-based versus product-based 
With objective-based projects, a general objective or problem is defined, and there are several 
different ways in which that objective could be reached. The project team have freedom to select 
what appears to be the most appropriate approach. 
With product-based projects, the product is already very strictly defined and the development 
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team’s job is to implement the specification with which they have been presented. 


Stakeholders 
These are people who have a stake or interest in the project In general, they could be users/clients 
or developers/implementers 
They could be: 
e Within the project team 
e Outside the project team, but within the same organization 
e Outside both the project team and the organization 
Different stakeholders may have different objectives - need to define common project objectives 
Project Leader is to recognize these different interests (good 
Communicator/Negotiator) 
Boehm & Ross - _Theory W‘ Win-Win 
Setting objectives 
e _What do we have to do to have a success?’ 
e Need for a project authority 
— Sets the project scope 
— Allocates/approves costs 
e Could be one person - or a group (Project Authority-most important-control- 
finance-monitor-modify objectives) 
— Project Board 
— Project Management Board 
— Steering committee 
Objectives 
Informally, the objective of a project can be defined by completing the statement: 


Rather like post-conditions for the project, Focus on what will be put in place, rather than 

how activities will be carried out 

e.g. ‘a new payroll application will be operational by 4th April’ not ‘design and code a new 
payroll application’ 

Objectives should be SMART 

S - specific, that is, concrete and well-defined 

M - measurable, that is, satisfaction of the objective can be objectively judged 

A - achievable, that is, itis within the power of the individual or group concerned to meet the target 
R - relevant/Resource Constrained, the objective must relevant to the true purpose of the project 
T - time constrained: there is defined point in time by which the objective should be achieved 
Goals/sub-objectives 

These are steps along the way to achieving the objective 

Informally, these can be defined by completing the sentence To reach objective X, the following 
must be in place 


Often a goal can be allocated to an individual. Individual might have the capability of achieving goal 
on their own, but not the overall objective e.g. 
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Overall objective - user satisfaction with software product Analyst goal - accurate 
requirements 
Developer goal - reliable software Measures of effectiveness 
How do we know that the goal or objective has been achieved? By a practical test, that can be 
objectively assessed. 
e.g. for user satisfaction with software product: 
e Repeat business - they buy further products from us 
e Number of complaints - if low etc etc 
e Measures of effectiveness 
e Performance Measurement- 
— To measure reliability - mtbf 
— Mean time between failures 
— Seek Predictive Measures 
e Large number of errors during code, inspections needed 


Brainstorming 
e Read the News article and find the Client‘s consideration /requirement before 
outsourcing a project. 
What is management? 
This involves the following activities: 
e Planning - deciding what is to be done 
e Organizing - making arrangements 
e Staffing - selecting the right people for the job 
e Directing - giving instructions 
Monitoring - checking on progress 
Controlling - taking action to remedy hold-ups 
Innovating - coming up with solutions when problems emerge 


Project Project Monitoring and Control 
Planning 7 F 
[ Project Plan Revision | Project 
Closing 


Project Initiation|~<——— Project Execution ——>|~«Project Closing 


Principal project management processes 


Project planning is an important responsibility of the project manager. During project planning, the 
project manager needs to perform a few well-defi ned activities that have been outlined below. Note 
that we have given a very brief description of these activities in this chapter. We will discuss these 
activities in more detail in subsequent chapters. Several best practices have been proposed for 
software project planning activities. 

While PRINCEZ is used extensively in the UK and Europe, similar software project management best 
practices have been put forward in the USA by the Project Management Institute’s ‘PMBOK’ 

which refers to their publication ‘A Guide to the Project Management Body of Knowledge.’ 

@ Estimation The following project attributes are estimated. 

@ Cost How much is it going to cost to complete the project? 
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@ Duration How long is it going to take to complete the project? 

@ Effort How much effort would be necessary for completing the project? 

The effectiveness of all activities such as scheduling and staffi ng, which are planned at a later stage, 
depends on the accuracy with which the above three project parameters have been estimated. 

@ Scheduling Based on estimations of effort and duration, the schedules for manpower and other 
resources are developed. 

@ Staffing Staff organization and staffing plans are made. 

@ Risk Management This activity includes risk identification, analysis, and abatement planning. 

@ Miscellaneous Plans This includes making several other plans such as quality assurance plan, 
configuration management plan, etc. 

Project monitoring and control activities are undertaken after the initiation of development 
activities. The aim of project monitoring and control activities is to ensure that the software 
development proceeds as planned. While carrying out project monitoring and control activities, a 
project manager may sometimes find it necessary to change the plan to cope with specifi c situations 
and make the plan more accurate as more project data becomes available. 


Management Control 

Management, in general, involves setting objectives for a system and then monitoring the 
performance of the system. In Figure 1.5 the ‘real world’ is shown as being rather formless. 
Especially in the case of large undertakings, there will be a lot going on about which management 
should be aware. This will involve the local managers in data collection. Bare details, such as 
‘location X has processed 2000 documents’, will not be very useful to higher management: data 


processing will be needed to transform this raw data into useful information. This might be in such 
forms as ‘percentage of records processed’, ‘average documents processed per day per person’ and 
‘estimated completion date’. It can be seen that a project plan is dynamic and will need constant 
adjustment during the execution of the project. Courses and books on project management (such as 
this one) often focus considerable attention on project planning. While this is to be expected, with 
nearly all projects much more time is spent actually doing the project rather than planning it. A 
good plan provides a foundation for a good project, but is nothing 
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without intelligent execution. The original plan will not be set in stone but will be modifi ed to 
take account of changing circumstances. 


Traditional versus Modern Project Management Practices 

Over the last two decades, the basic approach taken by the software industry to develop software 
has undergone a radical change. Hardly any software is being developed from scratch any more. 
Software development projects are increasingly being based on either tailoring some existing 
product or reusing certain pre-built libraries. In either case, two important goals of recent life cycle 
models are maximization of code reuse and compression of project durations. Other goals include 
facilitating and accommodating client feedbacks and customer participation in project development 
work, and incremental delivery of the product with evolving functionalities. Change requests from 
customers are encouraged, rather than circumvented. Clients on the other hand, are demanding 
further reductions in product delivery times and costs. These recent developments have changed 
project management practices in many signifi cant ways. In the following section, we will discuss 
some important differences between modern project management practices and traditional 
practices. 

@ Planning Incremental Delivery Few decades ago, projects were much simpler and therefore more 
predictable than the present day projects. In those days, projects were planned ith sufficient detail, 
much before the actual project execution started. After the project initiation, monitoring and control 
activities were carried out to ensure that the project execution proceeded as per plan. Now, projects 
are required to be completed over a much shorter duration, and rapid application development and 
deployment are considered key strategies. The traditional long-term planning has given way to 
adaptive short-term planning. Instead of making a long-term project completion plan, the project 
manager now plans all incremental deliveries with evolving functionalities. This type of project 
management is Software Project Management often called extreme project management. Extreme 
project management is a highly flexible approach to project management that concentrates on the 
human side of project management (e.g., managing project stakeholders), rather than formal and 
complex planning and monitoring techniques. 

@ Quality Management Of late, customer awareness about product quality has increased signifi 
cantly. Tasks associated with quality management have become an important responsibility of the 
project manager. The key responsibilities of a project manager now include assessment of project 
progress and tracking the quality of all intermediate artifacts. 

@ Change Management Earlier, when the requirements were signed off by the customer, any 
changes to the requirements were rarely entertained. Customer suggestions are now actively being 
solicited and incorporated throughout the development process. To facilitate customer feedback, 
incremental delivery models are popularly being used. Product development is being carried out 
through a series of product versions implementing increasingly greater functionalities. Also 
customer feedback is solicited on each version for incorporation. This has made it necessary for an 
organization to keep track of the various versions and revisions through which the product 
develops. Another reason for the increased importance of keeping track of the versions and 
revisions is the following. Application development through customization has become a popular 
business model. Therefore, existence of a large number of versions of a product and the need to 
support these by a development organization has become common. In this context, the project 
manager plays a key role in product base lining and version control. This has made change 
management a crucial responsibility of the project manager. Change management is also known as 
configuration management. 
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Step wise : an overview of project planning 


Planning is the most difficult process in project management This chapter describes a framework 
of basic steps in project planning. Many different techniques can be used but this chapter tells the 
overview of the steps and activities in each step of project planning. 

A major step in project planning is to plan in outline first and then in more detail. 


Following are the major steps in project planning 
Steps in Project Planning 


Step 0 : Select project 

Step 1 : Identify project scope and objectives Step 2 : Identify project infrastructure 

Step 3 : Analyze project characteristics 

Step 4 : Identify project products and activities Step 5: Estimate effort for each activity. 
Step 6 : Identify activity risks. Step 7 : Allocate resources Step 8 Review / Publicize pl\an 
Step 9 & 10: Execute plan / lower level of planning 


Each step of project planning has different activities to perform. Following the description of ach 
step with its activities 

Step 0 : Select project 

This is called step 0 because in a way of project planning , it is out side the main project planning 
process. Feasibility study suggests us that the project is worthwhile or not. 

Step 1 : Identify project scope and objectives 


The activities in this step ensure that all parties to the project agree on the objectives and are 
committed to the success of the project. 

Step 1.1 : Identify objectives and practical measures of the effectiveness in meeting those 
objectives 

Step 1.2 : Establish project authority 

Step 1.3 : Stakeholders analysis - Identify all stakeholders in the project and their interest. 

Step 1.4 : Modify objectives in the light of stakeholder anaylsis. 

Step 1.5 : Establish method of communication 


Step 2 : Identify project infrastructure 

Projects are rarely carried out in a vacuum. There is usually some kind of infrastructure into 
which the project must fit. Where the project manager are new to the organization , they must find 
out the precise nature of this infrastructure. 

Step 2.1: Identify relationship between the project and strategic planning 

Step 2.2 : Identify installation standards and procedures. 

Step 2.3 : Identify project team organization. 


Step 3 : Analyze project characteristics. 
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The general purpose of this part of planning operation is to ensure that the appropriate methods 
are used for the project. 

Step 3.1: Distinguish the project as either objective- product driven 

Step 3.2 : Analyze other project characteristics ( including quality -based ones) 

Step 3.3 : Identify high level project risks 
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Step 3.3 : Take into account user requirement concerning implementation. 
Step 3.4 : Select development methodology and life cycle approach. 
Step 3.5 : Review overall resources estimates 


1.2 Stepwise Planning(step 4- step 5 ) 


Step 4 Identify project products and activities 


e 4.1 Identify and describe project products - ‘what 
dowe have to produce?’ 


Selection 
| products 
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Products 


e The result of an activity 

e Could be (among other things) 
— physical thing (‘installed pc’), 
— a document (‘logical data structure’) 
— a person (‘trained user’) 


— a new version of an old product (‘updated 
software’) 
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Step 4 
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FIGURE 8.1 Product Flow Diagram for the creation of an ‘invitation to tander’ 
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Step 4.3 Recognize product instances 


The PBS and PFD will probably have identified generic 
products e.g. ‘software modules’ 


It might be possible to identify specific instances 
e.g. ‘module A’, ‘module B’ ... 


But in many cases this will have to be left to later, more 
detailed, planning 


4.4. Produce ideal activity network 


Identify the activities needed to create each product in 
thePFD 


More than one activity might be needed to create a 
singleproduct 


Hint: Identify activities by verb + noun but avoid 
‘produce...’ (too vague) 


Draw up activity network 
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An ‘ideal’ activity 


Generate 
7 test cases 


Analyse Obtain user Lp! Plan office m| Draf invitation 
@ Siting system requirements tayout d to tender 


a Caloulate 
volumes 


Survey 


potenta suppliers 


FIGURE B2? Beightmouth Collage payroll project activity network fragment 


Step 5:Estimate effort for each activity 
e 5.1 Carry out bottom-up estimates 
— distinguish carefully between effort and 
elapsed time 
e 5.2. Revise plan to create controllable activities 
— break up very long activities into a series of smaller ones 
— bundle up very short activities (create check lists?) 


Step 6: Identify activity risks 
e 6.1.I[dentify and quantify risks for activities 
— damage if risk occurs (measure in time lost or money) 
— likelihood if risk occurring 
e 6.2. Plan risk reduction and contingency measures 
— risk reduction: activity to stop risk occurring 
— contingency: action if risk does occur 
e 6.3 Adjust overall plans and estimates to take account of risks 
—e.g. add new activities which reduce risks associated with other activities e.g. training, 
pilot trials, information gathering 


Step 8: Review / Publicize plan 
Step 8.1 : Review quality aspects of the project plan. 
Step 8.2 : Document plans and obtain agreement. 


Step 9 & 10: Execute plan / lower level of planning 

Once the project is underway, plans will need to be drawn up in greater detail for each 
activity as it becomes due. Detailed and lower level of planning of the the later stages will 
need to be delayed because more information will be available nearer the start of the stage. 
Project planning is an iterative process. As the time approaches for the particular activities 
to be carried out they should be re-planned in more detail. 
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1.9 Activity Planning 
1. IDENTIFY THE ACTIVITY: 
Can you answer the following questions on the activity? 

a. What is the activity? Can you give a brief description of what it is and what 
will be involved? 

b. Who is the activity designed for? Is it for a club, a class, the whole student 
body? 

c. When is the activity planned for? Do you have a target date to plan your 
other deadlines around? 

d.How much will the activity cost? Do you have money allotted for the 
activity? Is it enough, and can you get more if needed? Will there be a fee 
charged for this activity and is there a bookkeeping system to handle that 
account? 

2. PLANNING THE ACTIVITY 
Step 1: Getting the manpower—Assemble members of your committee through asking 
people you know you can depend on and who are willing to work, in addition to having —sign 
ups|| or 
—recruiting||. 
Step 2: Getting the advisor—In many aspects of activity planning and following through, it 
is highly recommended that you seek an advisor, or an adult staff member who is willing to 
assist you in planning and supervising the follow through of your plans. 
Step 3: How should we plan the activity? 

a. Brainstorm: After getting your committee and advisor together, 
—brainstorm|| over every possible step that would be needed to plan the 
activity. As a guide, prior to brainstorming, remind the committee of the 
following guidelines: 

1. No idea is stupid, so no criticism of any suggestion is allowed. 2. Let the ideas flow freely, 
let everyone complete their suggestion before moving on to the next one. 
3. Keep going until every thought is exhausted. 

b. Weeding out ideas: After looking at the completed list of ideas, go over each 
item SEPERATELY and OBJECTIVELY to see if it is an idea that is definitely 
valid and essential to your planning. If not, eliminate it from the list. 

. Prioritize the items: After looking at the —slimmed down || list, asterisk (*) 
or underline those planning areas that would require MAJOR attention. Have 
the committee keep in mind that these areas may be the basis for the 
formation of —sub-committees||, or related task groups to be responsible for 
these MAJOR items. 

d. Chronological listing of the planning list: After sorting out the —major 
areas||, have the group list the items in —chronological order||, or list what 
should be completed from first to last. 


Assigning people to handle specific tasks: After agreeing to the organization of the planning 
of the activity, asking your committee members to handle the major areas identified by the 


group. 


e. Giving deadlines: Since every task was listed chronologically, now you can 
assign DEADLINES, or target dates by which these steps should be 
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completed. Make sure these dates are realistic. 
PRIOR TO THE ACTIVITY (Would suggest a target date of a week to 10 days prior) 

a. Check up: Make sure everyone has their areas of responsibility properly covered. If 
anything is not covered, find out why then make the proper 

arrangements. 

b. Activity day plan 
1. Diagram the facilities to be used: Get an idea of the physical area that you will be using. 
2. List the major stations/areas of responsibility for the day of 

the activity: Review stations then check manpower assignments to make sure these areas are 
covered. 
c. Simulation/run through: If possible, actually run through the activity in the facility to be 
used. For example, have the person assigned to handle registration for the activity actually 
practice having the —check in|] table go through the simulation of collecting money and 
stamping hands for a dance. 
The main thing to stress here is that as a chairperson, you are to supervise or —direct 
traffic||. You cannot physically do everything so make sure that those assigned know their 
duties well enough so that you won't have to worry about anything except for handling 
emergencies. 

4. DAY OF THE ACTIVITY 

a. Brief run through 

b. Make the proper acknowledgements: If you are emceeing the activity, take time to 

properly acknowledge your —crew]| for their work and efforts. 
5. AFTER THE ACTIVITY 


a. Send out your thank you notes/letters: This is the official acknowledgement of their 
efforts. Take the time even before the activity to prepare these notes or letters so that 
you can get them out immediately after the activity date. 

. Evaluation: Review and analyze your efforts and keep good records to help out the next 
person who will be responsible for this activity. Remember to list very specific 
recommendations. 
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13.1 INTRODUCTION 
Quality: 
> Quality is generally agreed to be ‘ a good thing’ . 
> In a practice what people really mean by the ‘quality’ of a system can be vague, undefined 
attribute. 
> We need to define precisely what qualities we require of a system. 
Objective assessment: 
> We need to judge objectively whether a system meets our quality requirements and this need 
measurement. 
> Critical for package selection, e.g., Brigette at Brightmouth College. 
Now days, delivering a high-quality product is one of the major objectives of all organizations. 
Traditionally, the quality of a product means that how much it gets fit into its specified purpose. A product 
is of good quality if it performs according to the user’s requirements. Good quality software should meet 
all objectives defined in the SRS document. It is the responsibility of the quality managers to ensure that 
the software attains a required level of quality. 
Waiting until the system is complete to measure quality is too late. 


During development, it's important to: 

> Assess the likely quality of the final system. 

> Ensure development methods will produce the desired quality. 
Potential customers, like Amanda at IOE, might focus on: 

> Checking if suppliers use the best development methods. 


> Ensuring these methods will lead to the required quality in the final system. 


13.2 THE PLACE OF SOFTWARE QUALITY IN PROJECT PLANNING 

Quality will be of concern at all stages of project planning and execution, but will be particular interest 
at Stepwise framework. 

Step 1 : Identifying project scope and objectives Some objective could relate to the quality of the 


application to be delivered. 

Step 2 : Identifying project infrastructure Within this step activity 2.2 involves identifying installation 
standards and procedures. Some of these will almost certainly be about quality requirements. 

Step 3 : Analyze project characteristics. In this activity the application to be implemented will be 
examined to see if it has any special quality requirements. 

Example: Safety-critical applications might require additional activities such as n-version 
development, where multiple teams develop versions of the same software to cross-check outputs. 
Step 4 : Identify the product and activities of the project. It is at that point the entry, exit and process 
requirement are identified for each activity. 

Step 8: Review and publicize plan. At this stage the overall quality aspects of the project plan are 
reviewed. 


| 0. Select project 


1. identify project 2. identify project 
scope and objectives infrastructure 


3. Analyse project 
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FIGURE 13.1 The place of software quality in Step Wise 


7. Allocate resources | 


13.3 THE IMPORTANCE OF SOFTWARE QUALITY 


Now a days, quality is the important aspect of all organization. Good quality software is the 
requirement of all users. There are so many reasons that describe why the quality of software is important; 
few among of those which are most important are described below: 
Increasingly criticality of software: 
> The final customer or user is naturally anxious about the general quality of software especially 
about the reliability. 
> They are concern about the safety because of their dependency on the software system such as 
aircraft control system are more safety critical systems. 
Earlier detection of errors during development- 


> As software is developed through a number of phases; output of one phase is given as input to the 
other one. So, if error in the initial phase is not found, then at the later stage, it is difficult to fix 
that error and also the cost indulged is more. 
The intangibility of software: 
> Difficulty in verifying the satisfactory completion of project tasks. 
> Tangibility is achieved by requiring developers to produce "deliverables" that can be examined 
for quality. 
Accumulating errors during software development: 
> Errors in earlier steps can propagate and accumulate in later steps. 


> Errors found later in the project are more expensive to fix. 
> The unknown number of errors makes the debugging phase difficult to control. 


13.4 DEFINING SOFTWARE QUALITY 


Quality is a rather vague term and we need to define carefully what we mean by it. For any software 


system there should be three specifications. 
e A functional specification describing what the system is to do 
e A quality specification concerned with how well the function are to operate 
e A resource specification concerned with how much is to be spent on the system. 
Attempt to identify specific product qualities that are appropriate to software , for instance, grouped 
software qualities into three sets. Product operation qualities, Product revision qualities and product 
transition qualities. 
Product operation qualities: 
Correctness: The extent to which a program satisfies its specification and fulfil user objective. 
Reliability: the extent to which a program can be expected to perform its intended function with required 
precision. 
Efficiency: The amounts of computer resource required by software. 
Integrity: The extent to which access to software or data by unauthorized persons can be controlled. 
Usability: The effort required to learn, operate, prepare input and interprets output. 
Product Revision Qualities: 
Maintainability: The effort required to locate and fix an error in an operational program 
Testability: The effort required to test a program to ensure it performs its intended function. 
Flexibility: The effort required to modify an operational program. 
Product Transition Qualities: 
Portability: The efforts require to transfer a program from one hardware configuration and or software 
system environment to another. 
Reusability: The extent to which a program can be used in other applications. 
Interoperability: The efforts required to couple one system to another. 
When there is concerned about the need for a specific quality characteristic in a software product then a 
quality specification with the following minimum details should be drafted. 
1. Definition/Description 
Definition: Clear definition of the quality characteristic. 
Description: Detailed description of what the quality characteristic entails. 
. Scale o Unit of Measurement: 
The unit used to measure the quality characteristic (e.g., faults per thousand lines of code). 
. Test 
Practical Test: The method or process used to test the extent to which the quality attribute exists. 
. Minimally Acceptable 
Worst Acceptable Value: The lowest acceptable value, below which the product would be 
rejected. 
. Target Range 


6. 


Planned Range: The range of values within which it is planned that the quality measurement 
value should lie. 

Current Value 

Now: The value that applies currently to the quality characteristic. 


Measurements Applicable to Quality Characteristics in Software 
When assessing quality characteristics in software, multiple measurements may be applicable. For 
example, in the case of reliability, measurements could include: 


1. 


2. 


Availability: 

Definition: Percentage of a particular time interval that a system is usable. 

Scale: Percentage (%). 

Test: Measure the system's uptime versus downtime over a specified period. 

Minimally Acceptable: Typically, high availability is desirable; specifics depend on system 
requirements. 

Target Range: E.g., 99.9% uptime. 

Mean Time Between Failures (MTBF): 

Definition: Total service time divided by the number of failures. 

Scale: Time (e.g., hours, days). 

Test: Calculate the average time elapsed between system failures. 

Minimally Acceptable: Longer MTBF indicates higher reliability; minimum varies by system 
criticality. 

Target Range: E.g., MTBF of 10,000 hours. 


. Failure on Demand: 


Definition: Probability that a system will not be available when required, or probability that a 
transaction will fail. 

Scale: Probability (0 to 1). 

Test: Evaluate the system's response to demand or transaction processing. 

Minimally Acceptable: Lower probability of failure is desired; varies by system criticality. 
Target Range: E.g., Failure on demand probability of less than 0.01. 


. Support Activity: 


Definition: Number of fault reports generated and processed. 

Scale: Count (number of reports). 

Test: Track and analyze the volume and resolution time of fault reports. 
Minimally Acceptable: Lower number of fault reports indicates better reliability. 
Target Range: E.g., Less than 10 fault reports per month. 


Maintainability and Related Qualities: 


Maintainability: How quickly a fault can be corrected once detected. 
Changeability: Ease with which software can be modified. 


Analyzability: Ease with which causes of failure can be identified, contributing to 
maintainability. These measurements help quantify and assess the reliability and maintainability 
of software systems, ensuring they meet desired quality standards. 


13.5 SOFTWARE QUALITY MODELS 

It is hard to directly measure the quality of a software. However, it can be expressed in terms of several 
attributes of a software that can be directly measured. 

The quality models give a characterization (hierarchical) of software quality in terms of a set of 
characteristics of the software. The bottom level of the hierarchical can be directly measured, thereby 


enabling a quantitative assessment of the quality of the software. 
There are several well-established quality models. 


1. 
2. 
3. 
4. 


McCall’ s model. 
Dromey’s Model. 
Boehm’s Model. 
ISO 9126 Model. 


Garvin’s Quality Dimensions: David Gravin, a professor of Harvard Business school, defined the 
quality of any product in terms of eight general attributes of the product. 


Performance: How well if performs the jobs. 

Features: How well it supports the required features. 

Reliability: Probability of a product working satisfactorily within a specified period of time. 
Conformance: Degree to which the product meets the requirements. 

Durability: Measure of the product life. 

Serviceability: Speed and effectiveness maintenance. 

Aesthetics: The look and feel of the product. 

Perceived quality: User’s opinion about the product quality. 


1) McCall’ Model: McCall defined the quality of a software in terms of three broad parameters: its 
operational characteristics, how easy it is to fix defects and how easy it is to part it to different 
platforms. These three high-level quality attributes are defined based on the following eleven 


attributes of the software: 


McCall’s Quality Model Triangle 


Maintainability AR Portability 


Flexibility J \ Reusability 
Testability J \ interoperability 
J \ 
Jf 


“ Product Product \ 


revision transition % 
~ \ 


' Product operations 


Correctness 
Reliability 
Efficiency 
integrity 
Usability 


Correctness: The extent to which a software product satisfies its specifications. 
Reliability: The probability of the software product working satisfactorily over a given 


duration. 


Efficiency: The amount of computing resources required to perform the required functions. 
Integrity: The extent to which the data of the software product remain valid. 

Usability: The effort required to operate the software product. 

Maintainability: The ease with which it is possible to locate and fix bugs in the software 
product. 

Flexibility: The effort required to adapt the software product to changing requirements. 
Testability: The effort required to test a software product to ensure that it performs its intended 
function. 

Portability: The effort required to transfer the software product from one hardware or software 
system environment to another. 

Reusability: The extent to which a software can be reused in other applications. 
Interoperability: The effort required to integrate the software with other software. 


Dromey’s model: Dromey proposed that software product quality depends on four major high-level 
properties of the software: Correctness, internal characteristics, contextual characteristics and certain 
descriptive properties. Each of these high-level properties of a software product, in turn depends on 
several lower-level quality attributes. Dromey’s hierarchical quality model is shown in Fig 13.2 
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Figure 13.2 Dromey’s quality model 


3) Boehm’s Model: Boehm’s suggested that the quality of a software can be defined based on these 
high-level characteristics that are important for the users of the software. These three high-level 
characteristics are the following: 

As-is -utility: How well (easily, reliably and efficiently) can it be used? 
Maintainability: How easy is to understand, modify and then retest the software? 
Portability: How difficult would it be to make the software in a changed environment? 


Boehm’s expressed these high-level product quality attributes in terms of several 
measurable product attributes. Boehm’s hierarchical quality model is shown in Fig 13.3 


Accountability 


Legibility 
Augmentability 


Figure 13.3 Boehm’s quality model 


13.6 ISO 9126 
> ISO 9126 standards was first introduced in 1991 to tackle the question of the definition of software 
quality. The original 13-page document was designed as a foundation upon which further more 
detailed standard could be built. ISO9126 documents are now very lengthy. 
Motivation might be- 
e Acquires who are obtaining software from external suppliers 
e Developers who are building a software product 
e Independent evaluators who are accessing the quality of a software product, not for themselves 
but for a community of user. 


> ISO 9126 also introduces another type of elements — quality in use- for which following element has 
been identified 
e Effectiveness : the ability to achieve user goals with accuracy and completeness; 
e Productivity : avoiding the excessive use of resources, such as staff effort, in achieving user 
goals; 
Safety: within reasonable levels of risk of harm to people and other entities such as business, 
software, property and the environment 


e Satisfaction: smiling users 


ISO 9126 is a significant standard in defining software quality attributes and providing a 
framework for assessing them. Here are the key aspects and characteristics defined by ISO 9126: 


ISO 9126 identifies six major external software quality characteristics: 

1. Functionality: 
Definition: The functions that a software product provides to satisfy user needs. 
Sub-characteristics: Suitability, accuracy, interoperability, security, compliance. 


Characteristic Sub-characteristics 
Functionality Suitability 
Accuracy 
Interoperability 
Functionality compliance 


Security 


‘Functionality Compliance’ refers to the degree to which the software adheres to application-related 
standard or legal requirements. Typically, these could be auditing requirement. ‘Interoperability’ refers 
to the ability of software to interact with others. 


2. Reliability: 
Definition: The capability of the software to maintain its level of performance under stated 
conditions. 
Sub-characteristics: Maturity, fault tolerance, recoverability. 


Characteristic Sub-characteristics 
Reliability Maturity 
Fault tolerance 
Recoverability 
Reliability compliance 


Maturity refers to frequency of failures due to fault in software more identification of fault more changes 
to remove them. Recoverability describes the control of access to a system. 


3. Usability: 
Definition: The effort needed to use the software. 
Sub-characteristics: Understandability, learnability, operability, attractiveness. 


Characteristic Sub-characteristics 

Usability Understandability 
Learnability 
Operability 
Attractiveness 
Usability compliance 


Understand ability is a clear quality to grasp. Although the definition attributes that bear on the user 
efforts for recognizing the logical concept and its applicability in our actually makes it less clear. 
Learnability has been distinguished from operability. A software tool might be easy to learn but time 
consuming to use say it uses a large number of nested menus. This is for a package that is used only 
intermittently but not where the system is used or several hours each day by the end user. In this case 
learnability has been incorporated at the expense of operability 
4. Efficiency: 
Definition: The ability to use resources in relation to the amount of work done. 
Sub-characteristics: Time behavior, resource utilization. 


5. Maintainability: 
Definition: The effort needed to make changes to the software. 
Sub-characteristics: Analyzability, modifiability, testability. 


Characteristic Sub-characteristics 
Efficiency Time behaviour 

Resource utilization 

Efficiency compliance 
Maintainability Analysability 

Changeability 

Stability 

Testability 

Maintainability compliance 


Analysability is the quality that McCall called diagnose ability, the ease with which the cause of failure 
can be determined. Changeability is the quality that others call flexibility : the latter name implies 
suppliers of the software are always changing it. Stability means that there is a low risk of a modification 
to software having unexpected effects. 


6. Portability: 
Definition: The ability of the software to be transferred from one environment to another. \ 
Sub-characteristics: Adaptability, install ability, co-existence. 


Characteristic Sub-characteristics 

Portability Adaptability 
Installability 
Coexistence 
Replaceability 
Portability compliance 


Portability compliance relates to those standards that have a bearing on portability. Replaceability refers 
to the factors that give upward compatibility between old software components and the new ones. 
‘Coexistence’ refers to the ability of the software to share resources with other software components; 
unlike' interoperability’, no direct data passing is necessarily involved 
ISO 9126 provides guidelines for the use of the quality characteristics. 
ISO 9126 provides structured guidelines for assessing and managing software quality characteristics 
based on the specific needs and requirements of the software product. It emphasizes the variation in 
importance of these characteristics depending on the type and context of the software product being 
developed. 
Steps Suggested After Establishing Requirements 
Once the software product requirements are established, ISO 9126 suggests the following steps: 
1. Specify Quality Characteristics: Define and prioritize the relevant quality characteristics based 
on the software's intended use and stakeholder requirements. 
Define Metrics and Measurements: Establish measurable criteria and metrics for evaluating 
each quality characteristic, ensuring they align with the defined objectives and user expectations. 
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3. Plan Quality Assurance Activities: Develop a comprehensive plan for quality assurance 
activities, including testing, verification, and validation processes to ensure adherence to quality 
standards. 

Monitor and Improve Quality: Continuously monitor software quality throughout the 
development lifecycle, identifying areas for improvement and taking corrective actions as 
necessary. 
Document and Report: Document all quality-related activities, findings, and improvements, and 
provide clear and transparent reports to stakeholders on software quality status and compliance. 
1. Judge the importance of each quality characteristic for the application. 
e Identify key quality characteristics (e.g., Usability, Efficiency, Maintainability). 
e Assign importance ratings to these characteristics based on their relevance to the application. 
Importance of Quality Characteristics: 
Reliability: Critical for safety-critical systems where failure can have severe consequences. Measures 
like mean time between failures (MTBF) are essential. 
Efficiency: Important for real-time systems where timely responses are crucial. Measures such as 
response time are key indicators. 
2. Select the external quality measurements within the ISO 9126 framework relevant to the 
qualities prioritized above. 
Determine appropriate external quality measurements that correspond to each quality 
characteristic. 
e Reliability: Measure with MTBF or similar metrics. 
e Efficiency: Measure with response time or time behavior metrics. 


Map measurements onto ratings that reflect user satisfaction. for example, the mappings might 
be as in Table 13.1. 

For response time, user satisfaction could be mapped as follows (hypothetical example): 

Excellent: Response time < | second 

Good: Response time 1-3 seconds 

Acceptable: Response time 3-5 seconds 

Poor: Response time > 5 seconds 


Identify the relevant internal measurements and the intermediate products in which they 
appear. 
e Identify and track internal measurements such as cyclomatic complexity, code coverage, 
defect density, etc. 
e Relate these measurements to intermediate products like source code, test cases, and 
documentation. 


Overall assessment of product quality: To what extent is it possible to combine ratings for 
different quality characteristics into a single overall rating for the software? 


e Use weighted quality scores to assess overall product quality. 


e Focus on key quality requirements and address potential weaknesses early to avoid the need 
for an overall quality rating later. 
Based on the ISO 9126 framework and your points: 
1. Measurement Indicators Across Development Stages: 
> Early Stages: Qualitative indicators like checklists and expert judgments are used to assess 
compliance with predefined criteria. These are subjective and based on qualitative assessments. 


> Later Stages: Objective and quantitative measurements become more prevalent as the software 
product nears completion. These measurements provide concrete data about software performance 
and quality attributes. 
2. Overall Assessment of Product Quality: 
> Combining ratings for different quality characteristics into a single overall rating for software 
is challenging due to: 
e Different measurement scales and methodologies for each quality characteristic. 


e Sometimes, enhancing one quality characteristic (e.g., efficiency) may compromise 
another (e.g., portability). 
> Balancing these trade-offs can be complex and context-dependent. 
3. Purpose of Quality Assessment: 
Software Development: Assessment focuses on identifying weaknesses early, guiding developers to 


meet quality requirements, and ensuring continuous improvement throughout the development lifecycle. 
Software Acquisition: Helps in evaluating software products from external suppliers based on 
predefined quality criteria. 

Independent Assessment: Aims to provide an unbiased evaluation of software quality for stakeholders 
like regulators or consumers. 

It seems like you're describing a method for evaluating and comparing software products based on their 
quality characteristics. Here's a summary and interpretation of your approach: 


Taste 13.2 Mapping response times onto user satisfaction 


Response time (seconds) 
<2 
2-3 
4-5 
6-7 
8-9 
>9 


The table 13.2 shows how different response times are mapped to quality scores on a scale of 0-5, with 
shorter response times receiving higher scores. A rating scale (e.g., 1-5) is used to reflect the importance 
of various quality characteristics. 


1. Rating for User Satisfaction: 
> Products are evaluated based on mandatory quality levels that must be met. Beyond these 
mandatory levels, user satisfaction ratings in the range of 0 to 5 are assigned for other desirable 
characteristics. 
> Objective measurements of functions are used to determine different levels of user satisfaction, 
which are then mapped to numerical ratings (see Table 13.2 for an example). 
2. Importance Weighting: 
> Each quality characteristic (e.g., usability, efficiency, maintainability) is assigned an importance 
rating on a scale of 1 to 5. 
> These importance ratings reflect how critical each quality characteristic is to the overall 
evaluation of the software product. 
3. Calculation of Overall Score: 
> Weighted scores are calculated for each quality characteristic by multiplying the quality score 
by its importance weight. 
> The weighted scores for all characteristics are summed to obtain an overall score for each 
software product. 
4. Comparison and Preference Order: 
> Products are then ranked in order of preference based on their overall scores. Higher scores 
indicate products that are more likely to satisfy user requirements and preferences across the 
evaluated quality characteristics. 
This method provides a structured approach to evaluating software products based on user satisfaction 
ratings and importance weights for quality characteristics. It allows stakeholders to compare and 
prioritize products effectively based on their specific needs and preferences. 


Taste 13.3 Weighted quality scores 


Product quality Importance Product A 
rating (a) 


Quality score Weighted score Quality score Weighted score 
(b) (a X b) (c) (aXe) 


Usability 


l 
Efficiency 2 
3 


Maintainability 


Overall 


This table 13.3 provides a comparison of two products (A and B) based on weighted quality 
scores. 

Each product quality (Usability, Efficiency, Maintainability) is given an importance rating. 
Product A and B are scored for each quality, and these scores are multiplied by the importance 
rating to obtain weighted scores. 

The total weighted scores are summed for each product to determine their overall ranking. 


It involves assessing software products by assigning quality scores to various characteristics, weighting 
these scores by their importance, and summing them to get an overall score. This approach helps to 
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objectively compare products based on user satisfaction and key quality metrics. 

By assigning scores to various qualities, weighting them by their importance, and summing these to get 
an overall score, it provides a comprehensive way to compare and rank software products. This ensures 
that both essential and desirable characteristics are considered in the assessment, leading to a more 
balanced and objective evaluation. 


13.7 PRODUCT AND PROCESS METRICS 


Users assess the quality of a software product based on its external attributes, whereas during 
development, the developers assess the product’s quality based on various internal attributes. 
The internal attributes may measure either some aspects of product or of the development process(called 
process metrics). 
1. Product Metrics: 
Purpose: Measure the characteristics of the software product being developed. 
Examples: 
Size Metrics: Such as Lines of Code (LOC) and Function Points, which quantify the size or 
complexity of the software. 
Effort Metrics: Like Person-Months (PM), which measure the effort required to develop the 
software. 
Time Metrics: Such as the duration in months or other time units needed to complete the 
development. 
2. Process Metrics: 
Purpose: Measure the effectiveness and efficiency of the development process itself. 
Examples: 
Review Effectiveness: Measures how thorough and effective code reviews are in finding defects. 
Defect Metrics: Average number of defects found per hour of inspection, average time taken to 
correct defects, and average number of failures detected during testing per line of code. 
Productivity Metrics: Measures the efficiency of the development team in terms of output per 
unit of effort or time. 
Quality Metrics: Such as the number of latent defects per line of code, which indicates the 
robustness of the software after development. 
Differences: 
> Focus: Product metrics focus on the characteristics of the software being built (size, effort, 
time), while process metrics focus on how well the development process is performing 
(effectiveness, efficiency, quality). 
Use: Product metrics are used to gauge the attributes of the final software product, aiding in 
planning, estimation, and evaluation. Process metrics help in assessing and improving the 
development process itself, aiming to enhance quality, efficiency, and productivity. 
Application: Product metrics are typically applied during and after development phases to 
assess the product's progress and quality. Process metrics are applied throughout the 
development lifecycle to monitor and improve the development process continuously. 
By employing both types of metrics effectively, software development teams can better manage projects, 
optimize processes, and deliver high-quality software products that meet user expectations. 


13.8 PRODUCT VERSUS PROCESS QUALITY MANAGEMENT 
In software development, managing quality can be approached from two main perspectives: product 
quality management and process quality management. Here’s a breakdown of each approach and their 
key aspects: 
Product Quality Management 
Product quality management focuses on evaluating and ensuring the quality of the software product itself. 
This approach is typically more straightforward to implement and measure after the software has been 
developed. 
Aspects: 
1. Measurement Focus: Emphasizes metrics that assess the characteristics and attributes of the final 
software product, such as size (LOC, function points), reliability (defects found per LOC), performance 
(response time), and usability (user satisfaction ratings). 
2. Evaluation Timing: Product quality metrics are often measured and evaluated after the software 
product has been completed or at significant milestones during development. 
3. Benefits: 

> Provides clear benchmarks for evaluating the success of the software development project. 

> Facilitates comparisons with user requirements and industry standards. 

> Helps in identifying areas for improvement in subsequent software versions or projects. 
4. Challenges: 

> Predicting final product quality based on intermediate stages (like early code modules or 

prototypes) can be challenging. 
> Metrics may not always capture the full complexity or performance of the final integrated product. 


Process Quality Management 
Process quality management focuses on assessing and improving the quality of the development 
processes used to create the software. This approach aims to reduce errors and improve efficiency 
throughout the development lifecycle. 
Aspects: 
1. Measurement Focus: Emphasizes metrics related to the development processes themselves, such as 
defect detection rates during inspections, rework effort, productivity (e.g., lines of code produced per 
hour), and adherence to defined standards and procedures. 
2. Evaluation Timing: Process quality metrics are monitored continuously throughout the development 
lifecycle, from initial planning through to deployment and maintenance. 
3. Benefits: 
> Helps in identifying and correcting errors early in the development process, reducing the cost and 
effort of rework. 
> Facilitates continuous improvement of development practices, leading to higher overall quality in 
software products. 
Provides insights into the effectiveness of development methodologies and practices used by the 
team. 


4. Challenges: 
> Requires consistent monitoring and analysis of metrics throughout the development lifecycle. 
> Effectiveness of process improvements may not always translate directly into improved product 
quality without careful management and integration. 
Integration and Synergy 
> While product and process quality management approaches have distinct focuses, they are 
complementary. 
> Effective software development teams often integrate both approaches to achieve optimal results. 
> By improving process quality, teams can enhance product quality metrics, leading to more 
reliable, efficient, and user-friendly software products. 


13.9 QUALITY MANGEMENT SYSTEMS 

BS EN ISO 9001:2000 

The British Standards institution (BSI) have engaged in the creation of standards for quality management 
systems. The British Standards is now called BS EN ISO 9001:2000, which is identical to the 
international standard, ISO 9001:2000. ISO 9000 describes the fundamental features of a quality 
management system (QMS) and its terminology. ISO 9001 describes how a QMS can be applied to a 
creation of products and provision of services. ISO 9004 applies to process improvement. 

An overview of BS EN ISO 9001:2000 QMS requirements 

ISO 9001:2000 is part of the ISO 9000 series, which sets forth guidelines and requirements for 


implementing a Quality Management System (QMS). The focus of ISO 9001:2000 is on ensuring that 
organizations have effective processes in place to consistently deliver products and services that meet 


customer and regulatory requirements. 
Key Elements: 
1. Fundamental Features: 
> Describes the basic principles of a QMS, including customer focus, leadership, involvement 
of people, process approach, and continuous improvement. 
> Emphasizes the importance of a systematic approach to managing processes and resources. 


2. Applicability to Software Development: 
> ISO 9001:2000 can be applied to software development by ensuring that the development 
processes are well-defined, monitored, and improved. 
> It focuses on the development process itself rather than the end product certification (unlike 
product certifications such as CE marking). 


3. Certification Process: 
> Organizations seeking ISO 9001:2000 certification undergo an audit process conducted by 
an accredited certification body. 
> Certification demonstrates that the organization meets the requirements of ISO 9001:2000 
and has implemented an effective QMS. 


4. Quality Management Principles: 

* Customer focus: Meeting customer requirements and enhancing customer satisfaction. 

* Leadership: Establishing unity of purpose and direction. 

Involvement of people: Engaging the entire organization in achieving quality objectives. 

Process approach: Managing activities and resources as processes to achieve desired outcomes. 

œ Continuous improvement: Continually improving QMS effectiveness. 

Application to Software Development 

In software development scenarios, ISO 9001:2000 helps organizations: 
Define and document processes related to software development, testing, and maintenance. 
Establish quality objectives and metrics for monitoring and evaluating software development 
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processes. 
Implement corrective and preventive actions to address deviations from quality standards. 
Ensure that subcontractors and external vendors also adhere to quality standards through 
effective quality assurance practices. 

Criticisms and Considerations 

Perceived Value: Critics argue that ISO 9001 certification does not guarantee the quality of the end 

product but rather focuses on the process. 

Cost and Complexity: Obtaining and maintaining certification can be costly and time-consuming, 

which may pose challenges for smaller organizations. 

Focus on Compliance: Some organizations may become overly focused on meeting certification 

requirements rather than improving overall product quality. 

Despite these criticisms, ISO 9001:2000 provides a structured framework that, when implemented 

effectively, can help organizations improve their software development processes and overall quality 

management practices. Measurement - to demonstrate that products conform to standards, and the QMS 

is effective, and to improve the effectiveness of processes that create products or services. 

It emphasizes continuous improvement and customer satisfaction, which are crucial aspects in the 

competitive software industry. 


BS EN ISO 9001:2000 outlines comprehensive requirements for implementing a Quality Management 


System (OMS). Here’s an overview of its key requirements and principles: 


Principles of BS EN ISO 9001:2000 
1. Customer Focus: 


Understanding and meeting customer requirements to enhance satisfaction. 
Leadership: 
Providing unity of purpose and direction for achieving quality objectives. 
Involvement of People: 
Engaging employees at all levels to contribute effectively to the QMS. 
Process Approach: 
% Focusing on individual processes that create products or deliver services. 
% Managing these processes as a system to achieve organizational objectives. 
Continuous Improvement: 


% Continually enhancing the effectiveness of processes based on objective measurements and 
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analysis. 
Factual Approach to Decision Making: 
Making decisions based on analysis of data and information. 
Mutually Beneficial Supplier Relationships: 
Building and maintaining good relationships with suppliers to enhance capabilities and performance. 


Activities in BS EN ISO 9001:2000 Cycle 


Understanding Customer Needs: 
Identifying and defining customer requirements and expectations. 
Establishing Quality Policy: 
Defining a framework for quality objectives aligned with organizational goals. 
Process Design: 
Designing processes that ensure products and services meet quality objectives. 
Allocation of Responsibilities: 
Assigning responsibilities for meeting quality requirements within each process. 
Resource Management: 
Ensuring adequate resources (human, infrastructure, etc.) are available for effective process 
execution. 
. Measurement and Monitoring: 
% Designing methods to measure and monitor process effectiveness and efficiency. 


“* Gathering data and identifying discrepancies between actual performance and targets. 
. Analysis and Improvement: 
Analyzing causes of discrepancies and implementing corrective actions to improve processes 
continually. 
Detailed Requirements 
1. Documentation: 


e Maintaining documented objectives, procedures (in a quality manual), plans, and records that 
demonstrate adherence to the QMS. 
e Implementing a change control system to manage and update documentation as necessary. 
2. Management Responsibility: 
Top management must actively manage the QMS and ensure that processes conform to quality 
objectives. 
3. Resource Management: 
Ensuring adequate resources, including trained personnel and infrastructure, are allocated to 
support QMS processes. 
4. Production and Service Delivery: 
Planning, reviewing, and controlling production and service delivery processes to meet 
customer requirements. 
Communicating effectively with customers and suppliers to ensure clarity and alignment on 
requirements. 


5. Measurement, Analysis, and Improvement: 
% Implementing measures to monitor product conformity, QMS effectiveness, and process 
improvements. 
% Using data and information to drive decision-making and enhance overall organizational 
performance. 


13.10 PROCESS CAPABILITY MODELS 


The evolution of quality assurance paradigms from product assurance to process assurance marks a 
significant shift in how organizations ensure quality in their outputs. Here’s an overview of some key 
concepts and methodologies related to process-based quality management: 
Historical Perspective 
1. Before the 1950s: 
Quality assurance primarily focused on extensive testing of finished products to identify defects. 
2. Shift to Process Assurance: 
% Later paradigms emphasize that ensuring a good quality process leads to good quality 
products. 
% Modern quality assurance techniques prioritize recognizing, defining, analyzing, and 
improving processes. 
Total Quality Management (TQM) 
1. Definition: 
*“* TQM focuses on continuous improvement of processes through measurement and redesign. 
** It advocates that organizations continuously enhance their processes to achieve higher levels 
of quality. 
Business Process Reengineering (BPR) 
1. Objective: 
** BPR aims to fundamentally redesign and improve business processes. 
% It seeks to achieve radical improvements in performance metrics, such as cost, quality, 
service, and speed 
To manage quality during development, process -based techniques are very important. SEI CMM, 
CMMI, ISO 15504, and Six Sigma are popular capability models. 


Process Capability Models 
1. SEI Capability Maturity Model (CMM) and CMMI: 
Developed by the Software Engineering Institute (SED, CMM and CMMI provide a 
framework for assessing and improving the maturity of processes. 
They define five maturity levels, from initial (ad hoc processes) to optimized (continuous 
improvement). 
CMMI (Capability Maturity Model Integration) integrates various disciplines beyond 
software engineering. 
. ISO 15504 (SPICE): 


“* ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability 
determination), is an international standard for assessing and improving process capability. 
“* It provides a framework for evaluating process maturity based on process attributes and 


capabilities. 


3. Six Sigma: 
% Six Sigma focuses on reducing defects in processes to a level of 3.4 defects per million 
opportunities (DPMO). 
% It emphasizes data-driven decision-making and process improvement methodologies like 
DMAIC (Define, Measure, Analyze, Improve, Control). 
Importance of Process Metrics 
During Product Development: 
% Process metrics are more meaningfully measured during product development compared to 
product metrics. 
% They help in identifying process inefficiencies, bottlenecks, and areas for improvement early in 
the development lifecycle. 


1. SEI Capability Maturity Model (SEI CMM) 


The SEI Capability Maturity Model (CMM) is a framework developed by the Software Engineering 
Institute (SEI) to assess and improve the maturity of software development processes within 
organizations. 
It categorizes organizations into five maturity levels based on their process capabilities and practices: 
SEI CMM Levels: 
1. Level 1: Initial 
Characteristics: 
¢* Chaotic and ad hoc development processes. 
% Lack of defined processes or management practices. 
** Relies heavily on individual heroics to complete projects. 
Outcome: 
“+ Project success depends largely on the capabilities of individual team members. 
% High risk of project failure or delays. 


2. Level 2: Repeatable 

Characteristics: 

% Basic project management practices like planning and tracking costs/schedules are in 
place. 

% Processes are somewhat documented and understood by the team. 

Outcome: 
“+ Organizations can repeat successful practices on similar projects. 
% Improved project consistency and some level of predictability. 


3. Level 3: Defined 
Characteristics: 
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Processes for both management and development activities are defined and documented. 
Roles and responsibilities are clear across the organization. 

Training programs are implemented to build employee capabilities. 

Systematic reviews are conducted to identify and fix errors early. 

Outcome: 


~~ 


ae 


oe 


+ 
* 


\7 


% Consistent and standardized processes across the organization. 
% Better management of project risks and quality. 


4. Level 4: Managed 
Characteristics: 

% Processes are quantitatively managed using metrics. 

% Quality goals are set and measured against project outcomes. 

“* Process metrics are used to improve project performance. 


Outcome: 
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% Focus on managing and optimizing processes to meet quality and performance goals. 
“* Continuous monitoring and improvement of project execution. 


5. Level 5: Optimizing 
Characteristics: 


> 


Continuous process improvement is ingrained in the organization's culture. 
Process metrics are analyzed to identify areas for improvement. 

Lessons learned from projects are used to refine and enhance processes. 
Innovation and adoption of new technologies are actively pursued. 
Outcome: 
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* Continuous innovation and improvement in processes. 
* High adaptability to change and efficiency in handling new challenges. 
“* Leading edge in technology adoption and process optimization. 

Use of SEI CMM: 

1) Capability Evaluation: Used by contract awarding authorities (like the US DoD) to assess 
potential contractors’ capabilities to predict performance if awarded a contract. 

2) Process Assessment: Internally used by organizations to improve their own process capabilities 
through assessment and recommendations for improvement. SEI CMM has been instrumental not 
only in enhancing the software development practices within organizations but also in 
establishing benchmarks for industry standards. 

It encourages organizations to move from chaotic and unpredictable processes (Level 1) to optimized 

and continuously improving processes (Level 5), thereby fostering better quality, efficiency, and 

predictability in software development efforts. 
Key process areas 


The Capability Maturity Model Integration (CMMI) is an evolutionary improvement over its predecessor, 


22 


the Capability Maturity Model (CMM). Here's an overview of CMMI and its structure: 
2. CMMI( Capability Maturity Model Integration): 


Evolution and Purpose of CMMI 
1. Evolution from CMM to CMMI: 
CMM Background: The original Capability Maturity Model (CMM) was developed in the late 
1980s by the Software Engineering Institute (SEI) at Carnegie Mellon University, primarily to 
assess and improve the software development processes of organizations, particularly those 
contracting with the US Department of Defense. 
Expansion and Adaptation: Over time, various specific CMMs were developed for different domains 
such as software acquisition (SA-CMM), systems engineering (SE-CMM), and people management 
(PCMM). These models provided focused guidance but lacked integration and consistency. 
2. Need for Integration: 
Challenges: Organizations using multiple CMMs faced issues like overlapping practices, 
inconsistencies in terminology, and difficulty in integrating practices across different domains. 
CMMI Solution: CMMI (Capability Maturity Model Integration) was introduced to provide a 
unified framework that could be applied across various disciplines beyond just software 
development, including systems engineering, product development, and services. 
Structure and Levels of CMMI 


1. Levels of Process Maturity: Like CMM, CMMI defines five maturity levels, each representing 


a different stage of process maturity and capability. 

These levels are: 

Level 1: Initial (similar to CMM Level 1) 

Level 2: Managed (similar to CMM Level 2) 

Level 3: Defined (similar to CMM Level 3) 

Level 4: Quantitatively Managed (an extension of CMM Level 4) 

Level 5: Optimizing (an extension of CMM Level 5) 

. Key Process Areas (KPAs): 
Definition: Similar to CMM, each maturity level in CMMI is characterized by a set of Key 
Process Areas (KPAs). These KPAs represent clusters of related activities that, when performed 
collectively, achieve a set of goals considered important for enhancing process capability. 
Gradual Improvement: KPAs provide a structured approach for organizations to incrementally 
improve their processes as they move from one maturity level to the next. 
Integration across Domains: Unlike the specific CMMs for various disciplines, CMMI uses a 
more abstract and generalized set of terminologies that can be applied uniformly across different 
domains. 
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Level Key process areas 
1. Initial Not applicable 


2. Managed Requirements management, project planning and monitoring and control, 
supplier agreement management, measurement and analysis, process 
and product quality assurance, configuration management 


3. Defined Requirements development, technical solution, product integration, 
verification, validation, organizational process focus and definition, 
training, integrated project management, risk management, integrated 
teaming, integrated supplier management, decision analysis and 
resolution, organizational environment for integration 


4, Quantitatively managed Organizational process performance, quantitative project management 


5. Optimizing Organizational innovation and deployment, causal analysis and resolution 


TABLE 13.4 CMMI key process areas 
Benefits of CMMI 


% Broad Applicability: CMMI's abstract nature allows it to be applied not only to software 
development but also to various other disciplines and industries. 
Consistency and Integration: Provides a unified framework for improving processes, reducing 
redundancy, and promoting consistency across organizational practices. 
Continuous Improvement: Encourages organizations to continuously assess and refine their 


processes to achieve higher levels of maturity and performance. 


3. 1S0 15504 Process assessment 

ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability determination), is 
a standard for assessing and improving software development processes. Here are the key aspects of ISO 
15504 process assessment: 

Process Reference Model 


e Reference Model: ISO 15504 uses a process reference model as a benchmark against which actual 
processes are evaluated. The default reference model is often ISO 12207, which outlines the processes in 
the software development life cycle (SDLC) such as requirements analysis, architectural design, 
implementation, testing, and maintenance. 

Process Attributes 

Nine Process Attributes: ISO 15504 assesses processes based on nine attributes, which are: 

1. Process Performance (PP): Measures the achievement of process-specific objectives. 

2. Performance Management (PM): Evaluates how well the process is managed and controlled. 

3. Work Product Management (WM): Assesses the management of work products like requirements 
specifications, design documents, etc. 

4. Process Definition (PD): Focuses on how well the process is defined and documented. 

5. Process Deployment (PR): Examines how the process is deployed within the organization. 

6. Process Measurement (PME): Evaluates the use of measurements to manage and control the process. 
7. Process Control (PC): Assesses the monitoring and control mechanisms in place for the process. 

8. Process Innovation (PI): Measures the degree of innovation and improvement in the process. 


9. Process Optimization (PO): Focuses on optimizing the process to improve efficiency and 
effectiveness. 
Processes are assessed on the basis of nine process attributes - see Table .1 3.5. 


Level Attribute Comments 


0. Incomplete 


. Performed 
process 


. Managed 
process 


. Established 
process 


. Predictable 
process 


1.1 Process 


performance 


Performance 
management 


Work product 
management 


Process 
definition 


Process 
deployment 


Process 
measurement 


Process 
control 


The process is not implemented or is 
unsuccessful 


The process produces its defined 
outcomes 


The process is properly planned and 
monitored 

Work products are properly defined and 
reviewed to ensure they meet requirements 


The processes to be carried out are 
carefully defined 


The processes defined above are properly 
executed by properly trained staff 


Quantitatively measurable targets are set 
for each sub-process and data collected to 
monitor performance 


On the basis of the data collected by 4.1 
corrective action is taken if there is 


unacceptable variation from the targets 


As a result of the data collected by 4.1, 
opportunities for improving processes 

are identified 

Process The opportunities for process improvement 


optimization are properly evaluated and where 
appropriate are effectively implemented 


. Optimizing .1 Process 
innovation 


TABLE 13.5 1S0 15504 framework for process capability 


Compatibility with CMMI 

Alignment with CMMI: ISO 15504 and CMMI share similar goals of assessing and improving software 
development processes. While CMMI is more comprehensive and applicable to a broader range of 
domains, ISO 15504 provides a structured approach to process assessment specifically tailored to 
software development. 

Benefits and Application 

e Benefits: ISO 15504 helps organizations: 

1) Evaluate their current processes against a recognized standard. 

2) Identify strengths and weaknesses in their processes. 

3) Implement improvements based on assessment findings. 


e Application: The standard is used by organizations to conduct process assessments either internally for 
improvement purposes or externally for certification purposes. 


Note: For a process to be judged to be at Level 3, for example, Levels 1 and 2 must also have been 


achieved. 
When assessors are judging the degree to which a process attribute is being fulfilled, they allocate one of 
the following scores: 


Level Interpretation 

N- not achieved 0 to 15% achievement 

P — partially achieved 15% to 50% achievement 
L -largely achieved 50% to 85% achievement 


F- fully achieved 85% achievement 


In order to assess the process attribute of a process at being at a certain level of achievement , indicators 
have to be found that provide evidence for the assessment. 
In the context of assessing process attributes according to ISO/IEC 15504 (SPICE), evidence is crucial 
to determine the level of achievement for each attribute. 
Here’s how evidence might be identified and evaluated for assessing the process attributes, taking the 
example of requirement analysis processes: 
Example of Assessing Requirement Analysis Processes 
1. Process Definition (PD): 
= Evidence: A section in the procedures manual that outlines the steps, roles, and 
responsibilities for conducting requirements analysis. 
Assessment: Assessors would review the documented procedures to ensure they clearly 
define how requirements analysis is to be conducted. This indicates that the process is 
defined (3.1 in Table 13.5). 
2. Process Deployment (PR): 
= Evidence: Control documents or records showing that the documented requirements 
analysis process has been used and followed in actual projects. 
Assessment: Assessors would look for signed-off control documents at each step of the 
requirements analysis process, indicating that the defined process is being implemented 
and deployed effectively (3.2 in Table 13.5). 
Using ISO/IEC 15504 Attributes 
1) Process Performance (PP): 
= Evidence: Performance metrics related to the effectiveness and efficiency of the requirements 
analysis process, such as the accuracy of captured requirements, time taken for analysis, and 
stakeholder satisfaction surveys. 
Assessment: Assessors would analyze the metrics to determine if the process meets its 
performance objectives (e.g., accuracy, timeliness). 
2) Process Control (PC): 
= Evidence: Procedures and mechanisms in place to monitor and control the requirements 


analysis process, such as regular reviews, audits, and corrective action reports. 


= Assessment: Assessors would review the control mechanisms to ensure they effectively 
monitor the process and address deviations promptly. 
3) Process Optimization (PO): 
= Evidence: Records of process improvement initiatives, feedback mechanisms from 
stakeholders, and innovation in requirements analysis techniques. 
= Assessment: Assessors would examine how the organization identifies opportunities for 
process improvement and implements changes to optimize the requirements analysis process. 
Importance of Evidence 
% Objective Assessment: Evidence provides objective data to support the assessment of process 
attributes. 
% Validation: It validates that the process attributes are not just defined on paper but are 
effectively deployed and managed. 
% Continuous Improvement: Identifying evidence helps in identifying areas for improvement and 
optimizing processes over time. 
Implementing process improvement 
Implementing process improvement in UVW, especially in the context of software development for 
machine tool equipment, involves addressing several key challenges identified within the organization. 
Here’s a structured approach, drawing from CMMI principles, to address these issues and improve 
process maturity: 
Identified Issues at UVW 
1. Resource Overcommitment: 


Issue: Lack of proper liaison between the Head of Software Engineering and Project Engineers 
leads to resource overcommitment across new systems and maintenance tasks simultaneously. 


Impact: Delays in software deliveries due to stretched resources. 
Requirements Volatility: 
Issue: Initial testing of prototypes often reveals major new requirements. 
Impact: Scope creep and changes lead to rework and delays. 
Change Control Challenges: 
Issue: Lack of proper change control results in increased demands for software development 
beyond original plans. 
Impact: Increased workload and project delays. 
Delayed System Testing: 
Issue: Completion of system testing is delayed due to a high volume of bug fixes. 
Impact: Delays in product release and customer shipment. 

Steps for Process Improvement 

1. Formal Planning and Control 
Objective: Introduce structured planning and control mechanisms to assess and distribute 
workloads effectively. 
Actions: 
% Implement formal project planning processes where software requirements are mapped 
to planned work packages. 


“* Define clear milestones and deliverables, ensuring alignment with both hardware and 
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software development phases. 
*% Monitor project progress against plans to identify emerging issues early. 
Expected Outcomes: 
% Improved visibility into project status and resource utilization. 
% Early identification of potential bottlenecks or deviations from planned schedules. 
“* Enable better resource allocation and management across different projects. 


Change Control Procedures 
Objective: Establish robust change control procedures to manage and prioritize system changes 


effectively. 

Actions: 
Define a formal change request process with clear documentation and approval 
workflows. 
Ensure communication channels between development teams, testing groups, and project 
stakeholders are streamlined for change notifications. 
Implement impact assessment mechanisms to evaluate the effects of changes on project 


timelines and resources. 
Expected Outcomes: 
Reduced scope creep and unplanned changes disrupting project schedules. 
Enhanced control over system modifications, minimizing delays and rework. 


Enhanced Testing and Validation 
Objective: Improve testing and validation processes to reduce delays in system testing and bug 
fixes. 
Actions: 
Strengthen collaboration between development and testing teams to ensure comprehensive 
test coverage early in the development lifecycle. 
Implement automated testing frameworks where feasible to expedite testing cycles. 
Foster a culture of quality assurance and proactive bug identification throughout the 
development phases. 
Expected Outcomes: 
% Faster turnaround in identifying and resolving bugs during testing. 
% Timely completion of system testing phases, enabling on-time product releases. 
Moving Towards Process Maturity Levels 
Level 1 to Level 2 Transition: 
Focus: Transition from ad-hoc, chaotic practices to defined processes with formal planning and control 
mechanisms. 
Benefits: Improved predictability in project outcomes, better resource management, and reduced 
project risks. 


resources progress reports 


Project process 
deliverables 


change requests 


5 Project as a ‘closed box' 


FIGURE 13. 


The next step would be to identify the processes involved in each stage of the development life cycle. 
As in Fig 13.6. The steps of defining procedures for each development task and ensuring that they are 
actually carried out help to bring an organization up to Level 3. 


Hardware definition 


Hardware System test error reports 
modifications Define software 


requirements 


Suggested Software Modifications 
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Review software 
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Software 
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Ficure 13.6 Process diagram 


Personal Software Process (PSP) 

PSP is based on the work of Watts Humphrey. PSP is suitable for individual use. PSP is a framework 
that helps engineers to measure and improve the way they work .It helps in developing personal skills 
and methods by estimating, planning, and tracking performance against plans, and provides a defined 
process which can be tuned by individuals. 

Time Management: PSP advocates that developers should rack the way they spend time. The actual 
time spent on a task should be measured with the help of a stop-clock to get an objective picture of the 
time spent. An engineer should measure the time he spends for various development activities such as 
designing, writing code, testing etc. 

PSP Planning: Individuals must plan their project. The developers must estimate the maximum. 
minimum, and the average LOC required for the product. They record the plan data in a project plan 
summary. 

The PSP is schematically shown in Figure 13.7 . As an individual developer must plan the personal 
activities and make the basic plans before starting the development work. While carrying out the activities 
of different phases of software development, the individual developer must record the log data using time 
measurement. 
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Figure 13.8 PSP levels 
During post implementation project review, the developer can compare the log data with the initial plan 


to achieve better planning in the future projects, to improve his process etc. The four maturity levels of 
PSP have schematically been shown in Fig 13.8. The activities that the developer must perform for 
achieving a higher level of maturity have also been annotated on the diagram. 


Six Sigma 


Motorola, USA , initially developed the six-sigma method in the early 1980s. The purpose of six sigma 
is to develop processes to do things better, faster, and at a lower cost. 

Six sigma becomes applicable to any activity that is concerned with cost, timeliness, and quality of 
results. Therefore, it is applicable to virtually every industry. 

Six sigma seeks to improve the quality of process outputs by identifying and removing the causes of 
defects and minimizing variability in the use of process. 

Six sigma is essentially a disciplined, data-driven approach to eliminate defects in any process. The 
statistical representation of six sigma describes quantitatively how a process is performing. To achieve 
six sigma, a process must not produce more than 3.4 defects per million defect opportunities. 

A six-sigma defect is defined as any system behavior that is not as per customer specifications. Total 
number of six sigma defect opportunities is then the total number of chances for committing an error. 
Sigma of a process can easily be calculated using a six-sigma calculator. 


Implementing Six Sigma Methodology at UVW 

UVW, a company specializing in machine tool equipment with sophisticated control software, can benefit 
significantly from implementing Six Sigma methodologies. Here’s how UVW can adopt and benefit from 
Six Sigma: Overview of Six Sigma Six Sigma is a disciplined, data-driven approach aimed at improving 


process outputs by identifying and eliminating causes of defects, thereby reducing variability in processes. 
The goal is to achieve a level of quality where the process produces no more than 3.4 defects per million 


opportunities. 
Steps to Implement Six Sigma at UVW 


1. 


Define: 

Objective: Clearly define the problem areas and goals for improvement. 

Action: Identify critical processes such as software development, testing, and deployment where 
defects and variability are impacting quality and delivery timelines. 

Measure: 

Objective: Quantify current process performance and establish baseline metrics. 

Action: Use statistical methods to measure defects, cycle times, and other relevant metrics in software 
development and testing phases. 

Analyze: 

Objective: Identify root causes of defects and variability in processes. 

Action: Conduct thorough analysis using tools like root cause analysis, process mapping, and 
statistical analysis to understand why defects occur and where process variations occur. 

Improve 

Objective: Implement solutions to address root causes and improve process performance. 

Action: Develop and implement process improvements based on the analysis findings. This could 
include standardizing processes, enhancing communication between teams (e.g., software 
development and testing), and implementing better change control procedures. 

Control: 

Objective: Maintain the improvements and prevent regression. 

Action: Establish control mechanisms to monitor ongoing process performance. Implement measures 
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such as control charts, regular audits, and performance reviews to sustain improvements. 
Application to UVW's Software Development 
Focus Areas: 
% Addressing late deliveries due to resource overcommitment. 
% Managing requirements volatility and change control effectively. o Enhancing testing processes to 
reduce defects and delays in system testing phases. 
Tools and Techniques: 


% Use of DMAIC (Define, Measure, Analyse, Improve, Control) for existing process improvements. 
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% Application of DMADV (Define, Measure, Analyse, Design, Verify) for new process or product 
development to ensure high-quality outputs from the outset. 
Benefits of Six Sigma at UVW 
% Improved Quality: Reduced defects and variability in software products. 
% Enhanced Efficiency: Streamlined processes leading to faster delivery times. 
** Cost Savings: Reduced rework and operational costs associated with defects. 


13.11 TECHNIQUES TO HELP ENHANCE SOFTWARE QUALITY 
The discussion highlights several key themes in software quality improvement over time, emphasizing 
shifts in practices and methodologies: 
Three main themes emerge: 
Increasing visibility: A landmark in this movement towards making the software development process 
more visible was the advocacy by the American software guru, Gerald Weinberg of egoless 
programming. Weinberg encouraged the simple practice of programmer looking at each other code. 
Procedure structure: 
e Initially, software development lacked structured methodologies, but over time, methodologies 
with defined processes for every stage (like Agile, Waterfall, etc.) have become prevalent. 
e Structured programming techniques and 'clean-room' development further enforce procedural 
rigor to enhance software quality 
Checking intermediate stages: 
e Traditional approaches involved waiting until a complete, albeit imperfect, version of software 
was ready for debugging. 
e Contemporary methods emphasize checking and validating software components early in 
development, reducing reliance on predicting external quality from early design documents. 
Inspections : 
= Inspections are critical in ensuring quality at various development stages, not just in coding but 
also in documentation and test case creation. 
It is very effective way of removing superficial errors from a piece of work. 
e It motivates developers to produce better structured and self-explanatory software. 
e It helps spread good programming practice as the participants discuss the advantages and 
disadvantages of specific piece of code. 
e It enhances team spirit. 
Techniques like Fagan inspections, pioneered by IBM, formalize the review process with trained 
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moderators leading discussions to identify defects and improve quality. 
Japanese Quality Techniques: 
= Learnings from Japanese quality practices, such as quality circles and continuous improvement, 
have influenced global software quality standards, emphasizing rigorous inspection and feedback 
loops. 
Benefits of Inspections: 
= Inspections are noted for their effectiveness in eliminating superficial errors, motivating 
developers to write better-structured code, and fostering team collaboration and spirit. 
= They also facilitate the dissemination of good programming practices and improve overall 
software quality by involving stakeholders from different stages of development. 
The general principles behind Fagan method 
e Inspections are carried out on all major deliverables. 
e All types of defects are noted. 


e Inspection can be carried out by colleagues at all levels except the very top. 


Inspection can be carried using a predefined set of steps. 
Inspection meeting do not last for more than two hours. 
The inspection is led by a moderator who has had specific training in the techniques. 
The participants have define rules. 
Checklist are used to assist the fault-finding process. 
e Material is inspected at an optimal rate of about 100 lines an hour. 
e Statistics are maintained so that the effectiveness of the inspection process can be monitored. 
Structured programming and clean room software development 
The late 1960s marked a pivotal period in software engineering where the complexity of software systems 
began to outstrip the capacity of human understanding and testing capabilities. Here are the key 
developments and concepts that emerged during this time: 
1. Complexity and Human Limitations: 
= Software systems were becoming increasingly complex, making it impractical to test every 
possible input combination comprehensively. 
= Edsger Dijkstra and others argued that testing could only demonstrate the presence of errors, not 
their absence, leading to uncertainty about software correctness. 
2. Structured Programming: 
= To manage complexity, structured programming advocated breaking down software into 
manageable components. 
= Each component was designed to be self-contained with clear entry and exit points, facilitating 
easier understanding and validation by human programmers. 
3. Clean-Room Software Development: 
= Developed by Harlan Mills and others at IBM, clean-room software development introduced a 
rigorous methodology to ensure software reliability. 


It involved three separate teams: 

> Specification Team: Gathers user requirements and usage profiles. 

> Development Team: Implements the code without conducting machine testing; focuses on 
formal verification using mathematical techniques. 

> Certification Team: Conducts testing to validate the software, using statistical models to 
determine acceptable failure rates. 


4. Incremental Development: 


= Systems were developed incrementally, ensuring that each increment was capable of 
operational use by end-users. 

= This approach avoided the pitfalls of iterative debugging and ad-hoc modifications, which 
could compromise software reliability. 


5. Verification and Validation: 


= Clean-room development emphasized rigorous verification at the development stage rather 
than relying on extensive testing to identify and fix errors. 

= The certification team's testing was thorough and continued until statistical models showed 
that the software failure rates were acceptably low. 


Overall, these methodologies aimed to address the challenges posed by complex software systems by 
promoting structured, systematic development processes that prioritize correctness from the outset rather 


than relying on post hoc testing and debugging. 
Clean-room software development, in particular, contributed to the evolution of quality assurance 
practices in software engineering, emphasizing formal methods and rigorous validation techniques. 


Formal methods 


Clean-room development, uses mathematical verification techniques. These techniques use 
unambiguous, mathematically based , specification language of which Z and VDM are examples. 
They are used to define preconditions and postconditions for each procedure. 

Precondition define the allowable states, before processing, of the data items upon which a 
procedure is to work. 

Post condition define the state of those data items after processing. The mathematical notation 
should ensure that such a specification is precise and unambiguous. 


Software quality circles(SWQC) 


SWQCs are adapted from Japanese quality practices to improve software development processes 
by reducing errors. 
Staff are involved in the identification of sources of errors through the formation of quality circle. 
These can be set up in all departments of an organizations including those producing software 
where they are known as software quality circle(SWQC). 
A quality circle is a group of four to ten volunteers working in the same area who meet for ,say, 
an hour a week to identify, analyze and solve their work -related problems. One of their number 
is a group leader and there could be an outsider a facilitator, who can advise on procedural matters. 
Associated with quality circles is the compilation of most probable error lists. For example, at 
IOE, Amanda might find that the annual maintenance contracts project is being delayed because 
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of errors in the requirements specifications. 
Compilation of Most Probable Error Lists 
1. Identification of Common Errors: Teams, such as those in quality circles, assemble to identify the 
most frequent types of errors occurring in a particular phase of software development, such as 
requirements specification. 
2. Analysis and Documentation: The team spends time analyzing past projects or current issues to 
compile a list of these common errors. This list documents specific types of mistakes that have been 
identified as recurring. 
3. Proposing Solutions: For each type of error identified, the team proposes measures to reduce or 
eliminate its occurrence in future projects. 
For example: 
Example Measure: Producing test cases simultaneously with requirements specification to ensure early 
validation. 
Example Measure: Conducting dry runs of test cases during inspections to catch errors early in the 
process. 
4. Development of Checklists: The proposed measures are formalized into checklists that can be used 
during inspections or reviews of requirements specifications. These checklists serve as guidelines to 
ensure that identified errors are systematically checked for and addressed. 
5. Implementation and Feedback: The checklists are implemented into the software development 
process. Feedback mechanisms are established to evaluate the effectiveness of these measures in reducing 
errors and improving overall quality. 
Benefits of Most Probable Error Lists 
Improved Quality: By proactively identifying and addressing common errors, the quality of 
requirements specifications (or other phases) improves. 
Efficiency: Early detection and prevention of errors reduce the need for costly corrections later in the 
development cycle. 
Standardization: Checklists standardize the inspection process, ensuring that critical aspects are 
consistently reviewed. This approach aligns well with quality circles and other continuous improvement 
methodologies by fostering a culture of proactive problem-solving and learning from past experiences. 
Lessons learnt reports 
e Another way by which an organization can improve its performance is by reflecting on the 
performance of a project at its immediate end when the experience is still fresh. This reflection 
may identify lessons to be applied to future projects. 
Project Managers are required to write a Lessons Learnt report at the end of the project. This 
should be distinguished from a Post Implementation Review (PIR). The PIR is often produced by 
someone who was not involved in the original project, in order to ensure neutrality. 


13.12 Testing 


The final judgement of the quality of the application is whether it actually works correctly when executed. 
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Figure 13.9 -process model 


Considering the diagrammatic representation of V-Model , which stress the necessity of 
validation activities that match the activities creating the products of the project. 
The V-process model is expanding the activity box ‘testing’ in the waterfall model. 
Each step has a matching validation process which can , where defects are found, cause a loop 
back to the corresponding development stage and a reworking of a following step. 
Verification verses Validation: 
Both are bug detection techniques which helps to remove errors in software. 
The main difference between these two techniques are the following: 
% Verification is the process of determining whether the output of one phase of software 
development conforms to that of its previous phase. For example, a verification step can be to 
check if the design documents produced after the design step conform to the requirement 
specification. 
Validation is the process of determining whether fully developed software conforms to its 
requirements specification. Validation is applied to the fully developed and integrated software 
to check if it satisfies customer’s requirements. 
Verification is carried put during development process to check of the development activities are 
being carried out correctly , where as 
Validation is carried out towards the end of the development process to check if the right product 
as required by the customer had been developed. 


All the boxes in the right hand of the V-process model of Fig.13.9 correspond to verification 
activities except the system testing block which corresponds to validation activity. 


Test case Design 

There are two approaches to design test cases: 
1) Black-box approach 
2) White-box(or glass-box) approach. 
In black-box approach, test cases are designed using only the functional specification of the software. 
That is, test cases are designed solely based on an analysis of the input/output behavior. Hence black- 
box testing is also known as functional testing and also as requirement-driven testing. 
Design of white-box test cases requires analysis of the source code, It is also called structural testing 
or structure-driven testing. 


Levels of Testing: 


A software product is normally tested at three different stages or levels. These three testing stages 
are: 
1) Unit Testing 
2) Integration Testing 
3) System Testing 
During unit testing, the individual components (or units) of a program are tested. For every module, unit 
testing is carried out as soon as the coding for it is complete. Since every module is tested separately, 
there is a good scope for parallel activities during unit testing. 
After testing all the units individually, the units are integrated over a number of steps and tested after 
each step of integration (Integration testing). 
Finally, the fully integration system is tested (System testing). 
Testing Activities: 
Testing involves performing the following main activities: 
1) Test Planning: Test Planning consists of determining the relevant test strategies and planning for 
any test bed that may be required. A test bed usually includes setting up the hardware or simulator. 


2) Test Case Execution and Result Checking: Each test case is run and the results are compared 
with the expected results. A mismatch between the actual result and expected results indicates a 
failure. The test cases for which the system fails are noted down for test reporting. 


Test Reporting: When the test cases are run, the tester may raise issues, that is, report 
discrepancies between the expected and the actual findings. A means of formally recording these 
issues and their history is needed. A review body adjudicates these issues. The outcome of this 
scrutiny would be one of the following: 
e The issue is dismissed on the grounds that there has been a misunderstanding of a 
requirement by the tester. 
The issue is identified as a fault which the developers need to correct -Where development 
is being done by contractors, they would be expected to cover the cost of the correction. 
It is recognized that the software is behaving as specified, but the requirement originally 
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agreed is in fact incorrect. 
e The issue is identified as a fault but is treated as an off-specification -It is decided that the 
application can be made operational with the error still in place. 
4) Debugging: For each failure observed during testing, debugging is carried out to identify the 
statements that are in error. 


5) Defect Retesting: Once a defect has been dealt with by the development team, the corrected code 
is retested by the testing team to check whether the defect has successfully been addressed . Defect 
retest is also called resolution testing. The resolution tests are a subset of the complete test suite 
(Fig: 13.10). 
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Ficure 13.10 Types of test cases in the original 
test suite after a change 


6) Regression Testing: Regression testing checks whether the unmodified functionalities still 
continue to work correctly. Thus, whenever a defect is corrected and the change is incorporated in 
the program code, the change introduced to correct an error could actually introduce errors in 
functionalities that were previously working correctly. 


7) Test Closure: Once the system successfully passes all the tests, documents related to lessons 
learned, results, logs etc., are achieved for use as a reference in future projects. 


Who Performs Testing: 
Many organizations have separate system testing groups to provide an independent assessment of 
the correctness of software before release. In other organizations, staff is allocated to a purely 
testing role but work alongside the develops instead of a separate group. 


Test Automation: 
1) Testing is most time consuming and laborious of all software development. With the growing size 
of programs and the increased importance being given to product quality, test automation is 
drawing attention. 


Test automation is automating one or some activities of the test process. This reduces human effort 
and time which significantly increases the thoroughness of testing. 


With automation, more sophisticated test case design techniques can be deployed. By using the 
proper testing tools automated test results are more reliable and eliminates human errors during 
testing. 


Every software product undergoes significant change overtime. Each time the code changes, it 
needs to be tested whether the changes induce any failures in the unchanged features. Thus the 
originally designed test suite need to be run repeatedly each time the code changes. Automated 
testing tools can be used in repeatedly running the same set of test cases. 


Types of Automated Testing Tools 


> Capture and Playback Tools: In this type of tools, the test cases are executed manually only once. 
During manual execution , the sequence and values of various inputs as the outputs produced are 
recorded. Later, the test can be automatically replayed and the results are checked against the 
recorded output. 
Advantage: This tool is useful for regression testing. 
Disadvantage: Test maintenance can be costly when the unit test changes , since some of the 
captured tests may become invalid. 


Automated Test Script Tool: Test Scripts are used to drive an automated test tool. The scripts 
provide input to the unit under test and record the output. The testers employ a variety of languages 
to express test scripts. 
Advantage: Once the test script is debugged and verified, it can be rerun a large number of 
times easily and cheaply. 
Disadvantage: Debugging test scripts to ensure accuracy requires significant effort. 
Random Input Test Tools: In this type of an automatic testing tool, test values are randomly 
generated to cover the input space of the unit under test. The outputs are ignored because analyzing 
them would be extremely expensive. 
Advantage: This is relatively easy and cost-effective for finding some types of defects. 
Disadvantage: Is very limited form of testing. It finds only the defects that crash the unit under 
test and not the majority of defects that do not crash but simply produce incorrect results. 


> Model-Based Test Tools: A model is a simplified representation of program. These models can 
either be structural models or behavioral models. Examples of behavioral models are state models 
and activity models. A state model-based testing generates tests that adequately cover the state space 
described by the model. 


Estimation of latent errors: 
The methods of estimating the number of latent errors in software during testing: 


1) Using Historical Data :If historical error data from past projects are available, you can use this 


data to estimate the number of errors per 1000 lines of code. This method allows you to predict 
the number of errors likely to be found in a new system development of a known size. 


Seeding Known Errors 


During testing, seed the software with known errors. 

For example, introduce 10 known errors into the code. 

After testing, suppose 30 errors are found, of which 6 are the seeded errors. 

This implies that 60% of the seeded errors were detected. 

Thus, 40% of the errors are still undetected. 

Using this method, you can estimate the total number of errors in the software using the formula: 


Estimated Total Errors=(TotalErrors Found/Seeded Errors Found)xTotal Number of Seeded errors. 


3) Alternative Approach by Tom Gilb---Independent Reviews 


Instead of seeding known errors, use independent reviewers to inspect or test the same code. 
Collect three counts: 


o nl: Number of valid errors found by reviewer A 
o n2: Number of valid errors found by reviewer B 
o nl2: Number of cases where the same error is found by both A and B 
The smaller the proportion of errors found by both A and B compared to those found by only 
one reviewer, the larger the total number of errors likely to be in the software. 
Estimate the total number of errors using the formula: 
n=(nlxn2)/n12 


This method helps in estimating the number of latent errors without deliberately introducing known 
errors into the software. 


For example, A finds 30 errors and B finds 20 errors of which 15 are common to both A and B . Thes 
estimated total number of errors would be: 


(30*20)/15=40 


13.13 SOFTWARE RELIABILITY: 

> The reliability of a software product denotes trustworthiness or dependability. 

> It can be defined as the probability of its working correctly over a given period of time. 
Software product having a large number of defects is unreliable. Reliability of the system will improve 
if the number of defects in it is reduced. 
Reliability is a observer dependent, it depends on the relative frequency with which different users invoke 
the functionalities of a system. It is possible that because of different usage patterns of the available 
functionalities of software, a bug which frequently shows up for one user, may not show up at all for 
another user, or may show up very infrequently. 
Reliability of the software keeps on improving with time during the testing and operational phases as 
defects are identified and repaired. The growth of reliability over the testing and operational phases can 
be modelled using a mathematical expression called Reliability Growth Model (RGM). 
Popular RGMs (Explanation in Page 53) 


e Jelinski-Moranda model 
e Littlewood-Verrall model 
e Goel-Okumoto model 


RGMs help predict reliability levels during the testing phase and determine when testing can be stopped. 


Challenges in Software Reliability which makes which makes difficult to measure than hardware 
reliability. 

e Dependence on the specific location of bugs 

e Observer-dependent nature of reliability 

e Continuous improvement as errors are detected and corrected. 
Hardware vs. Software Reliability 


> Hardware failures typically result from wear and tear, whereas software failures are due to bugs. 


> Hardware failure often requires replacement or repair of physical components. Software failures 
need bug fixes in the code, which can affect reliability positively or negatively. 


> Hardware Reliability: Concerned with stability and consistent inter-failure times. 
Software Reliability: Aims for growth, meaning an increase in inter-failure times as bugs are fixed. 
> Hardware: Shows a "bathtub" curve where failure rate is initially high, decreases during the useful 
life, and increases again as components wear out. Software: Reliability generally improves over time 
as bugs are identified and fixed, leading to decreased failure rates 


Figure 13.11(a): Illustrates the hardware product's failure rate over time, depicting the "bathtub" curve. 
Figure 13.11(b): Shows the software product's failure rate, indicating a decline in failure rate over time due 
to bug fixes and improvements. 
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Ficure 13.11 Reliability growth with time for hardware and software products 


Software Reliability Metrics 
The six metric that correlate with reliability as follows: 


1) Rate of Occurrence of Failure (ROCOF): 
e Measures the frequency of occurrences of failures. 
e Calculated as the ratio of total failures observed to the duration of observation. 
e Limited applicability for non-continuously running software. Ex: Library software is idle 
until a book issue request is made. 


2) Mean Time to Failure (MTTF): 


Time between two successive failures, averaged over a large number of failures. 
Calculation involves summing up time intervals between failures and dividing by the number 
of failures. MTTF can be calculated as =—**“?? 


Only runtime is considered, excluding downtime for fixes. 


3) Mean Time to Repair (MTTR): 
e Average time required to fix an error. 
e Measures the time taken to track and fix failures 


4) Mean Time Between Failures (MTBF): 
e Sum of MTTF and MTTR. —> MTBF=MTTF+MTTR. 
e Indicates the expected time until the next failure after a failure is fixed. 


5) Probability of Failure on Demand (POFOD): 
e POFOD measures likelihood of system failure when a service request is made. For 
example, POFOD of 0.001 means that 1 out of every 1000 service requests would result in 
a failure. 
Suitable for systems not required to run continuously. 


6) Availability: 
e Measures how likely the system is available for use during a given period. 
e Takes into account both failure occurrences and repair times. 


Types of Software Failures 
e Transient: Failures occurring only for certain inputs while invoking a function. 
e Permanent: Failures occurring for all inputs while invoking a function. 
e Recoverable: System can recover without shutting down. 
e Unrecoverable: System needs to be restarted to recover. 
e Cosmetic: Minor irritations without incorrect result 


Reliability Growth Modeling 
e Definition: Mathematical models predicting how software reliability improves as errors are 
detected and fixed. 
e Application: Used to predict reliability levels and determine when to stop testing. 
1) Jelinski and Moranda Model 


e Model Characteristics: 


e A step function model assuming reliability increases by a constant increment with each error fix. 
e Assumes perfect error fixing, meaning all errors contribute equally to reliability growth. 


e Typically, unrealistic as different errors contribute differently to growth. Reliabity growth 
predicted using this model has been shown in Figure 13.12. 


Time — 


Figure 13.12 Jelinski-Moranda model 


e Failure Rate Equation: 
Instantaneous failure rate, or hazard rate, is given by 


Z(1)=K(N-1+1)Z(i) = K(N -i+ 1)Z(@)=K(N-1+1), 
where K is a constant, 

N is the total number of errors, and 

‘t’ is the interval between the i and (i+1) th failure. 


2) Littlewood and Verall’s Model 


This model allows for negative reliability growth, acknowledging that repairs can introduce new 
errors. 

It models the impact of error repairs on product reliability, which diminishes over time as larger 
contributions to reliability are addressed first. 

Uses Gamma distribution to treat an error’s contribution to reliability improvement as an 
independent random variable. 


3) Goel-Okutomo Model 


This model assumes exponentially distributed execution times between failures and models the 
cumulative number of failures over time. (,1¢t)) ,expected number of failures between time t 
and tt+At . 
It is assumed that it follows a non-homogeneous Poisson process (NHPP) ie., expected number 
of occurrences for any time t to t+At is proportional to the expected number of undetected 
errors at time t. 

o Therate of failures decreases exponentially over time. 

o The model assumes immediate and perfect correction once a failure is detected. 

e The number of failures over time if given in Figure 13.13. The number of failures at time t can 
be given by p(t)=N(1—e—bt), 
where N=Expected total number of defects in the code and 
b is the rate at which the failure rate decreases. 


Graph: Illustrates the expected total number of errors over execution time, showing an initial rapid 
increase in detected errors, which slows down as more errors are corrected. 
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Ficure 13.13 Goel-Okutomo reliability growth model 


13.14 QUALITY PLANS 

e Organizations produce quality plans for each project to show how standard quality procedures and 
standards from the organization's quality manual will be applied to the project. 
e If quality-related activities and requirements have been identified by the main planning process, a 
separate quality plan may not be necessary. 


e When producing software for an external client, the client’s quality assurance staff might require a 
dedicated quality plan to ensure the quality of the delivered products. 


Function of a Quality Plan: 

e A quality plan acts as a checklist to confirm that all quality issues have been addressed during the 
planning process. 

e Most of the content in a quality plan references other documents that detail specific quality procedures 
and standards. 

Components of a Quality Plan 

A quality plan might include: 

Purpose and scope of the plan 

List of references to other documents 

Management arrangements: Including organization, tasks, and responsibilities 
Documentation to be produced 

Standards, practices, and conventions 

Reviews and audits 

Testing 

Problem reporting and corrective action 

Tools, techniques, and methodologies 

Code, media, and supplier control 

Records collection, maintenance, and retention 

Training 

Risk management: Methods of risk management to be used 
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